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The  usual  approach  to  satisfy  requirements  for  increased  avionics  performance 
has  been  to  place  emphasis  on  the  selection  of  the  best  subsystems  available  or 
on  the  creation  of  new  subsystems.  However,  allowing  subsystem  performance  to 
drive  avionics  system  design  results  in  inflated  costs  and  problems  in  mainte- 
nance and  retrofit.  Subsystems  that  are  designed  for  maximum  performance 
become  increasingly  complex  and  are  often  incompatible  unless  interface  require- 
ments are  considered  early  in  the  design  effort.  This  effort  requires  not  only 
a conceptual  plan,  but  a realistic  evaluation  of  how  the  coupled  subsystems 
will  interact  under  all  critical  flight  conditions. 

The  trends  toward  consideration  of  avionics  hardware  from  the  systems'  view- 
point and  toward  the  increasing  use  of  modularized,  digital  hardware  put  in- 
creasing demand  on  effective  use  of  simulation  facilities  to  ensure  reliable, 
cost-effective  avionics  systems. 

This  Facility/Capability  Manual  for  the  simulation  facilities  of  AFAL  has 
been  developed  as  a means  for  increasing  the  effectiveness  of  these  important 
technical  resources. 

The  primary  objective  of  this  manual  is  to  document  the  total  simulation 
capability  in  a manner  which  will  serve  several  groups: 

1.  Those  members  of  the  AFAL  directorate  charged  with  planning  or  approval 
of  the  simulation  facilities. 

2.  Potential  users  with  a need  to  understand  the  general  capabilities  and 
limitations  of  the  simulation  facilities. 

3.  Actual  users  of  the  facilities  with  a need  to  plan  simulations,  document 
input  data,  conduct  or  coordinate  simulations,  and  interpret  results. 

4.  Members  of  the  AFAL  staff  who  are  involved  in  updating,  enlarging,  or 
deleting  simulation  capabilities. 

A secondary  objective  of  this  manual  is  to  document  the  relationships 
between  the  various  facilities,  which  may  enhance  their  interaction  and,  thus 
Improve  the  cost-effectiveness  of  the  overall  AFAL  simulation  capability. 

The  manual  achieves  these  objectives  by  presenting  introductory  and  summary 
material  in  Section  I and  by  presenting  more  detailed  descriptive  material  in 
subsequent  sections.  The  contents  of  Section  I address  the  Laboratory 
capabilities  from  a planning/management  viewpoint  by  relating  the  Laboratory 
mission  to  present  facility  capability  through  the  development  of  a conceptual 
simulation  class  structure.  The  contents  of  subsequent  sections  of  this  manual 
address  specific  facility/capability  from  a potential -user  viewpoint.  Both 
hardware  and  software  availability  are  documented.  The  technical  level  of 
these  sections  is  such  that  available  capability  can  be  determined  and  some 
insight  can  be  gained  regarding  user  interface. 
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SECTION  I 

INTRODUCTION  AND  EXECUTIVE  SUMMARY 

Thf  Air  Fort-o  Avionics  Laboratory  (AFAL)  at  WriKht-Patterson  Air  Force  Base  is  the 
focal  point  for  development  of  new  avionics  technology  for  the  Air  Force.  In  order  to  carry 
out  this  responsibility,  :i  significant  capability  to  simulate  physical  avionics  systems  and 
components  has  been  created  by  the  AFAL  divisions.  Of  prime  concern  is  the  effective  use 
of  the.si'  simulation  facilities  in  the  face  of  continually  increasing  performance  requirements, 
technological  advanct*s,  imd  rising  flight-U'st  costs. 


The  usual  approach  to  satisfy  requirements  for  increased  avionics  performance  has  been 
to  place  emphasis  on  the  selection  of  the  best  subsystems  available  or  on  the  creation  of  new 
subsystems.  However,  allowing  subsystem  performance  to  drive  avionics  system  design 
results  in  inflated  costs  and  problems  in  maintenance  and  retrofit.  Subsystems  that  are 
designed  for  maximum  (H-rformance  Ix-come  increasingly  complex  and  are  often  incom- 
I patible  unless  interface  requirements  tue  considert*d  early  in  the  design  effort.  This  effort 

• requires  not  only  a conceptual  plan,  but  a realistic  evaluation  of  how  the  coupled  sub- 

i systems  will  interact  under  all  critical  flight  conditions.  New  technology  in  components  for 

I avionics  systems  continually  suggists  new  system  implementiitions,  which  must  be  explored. 

! For  example,  there  is  a distinct  tnmd  at  the  present  towards  digital  techniques  in  all  aspects 

I of  electronics.  Micniproci'ssor  technology  has  promoted  greater  utilization  of  software  for 

functions  previously  jH»rformed  by  hiu-dware.  The  tnuids  toward  consideration  of  avionics 
hardware  from  the  systems'  viewpoint  and  toward  the  increasing  use  of  modularized,  digital 
haixlwart'  put  increasing  demand  on  effective  use  of  simulation  facilities  to  ensure  ndiable, 
cost-effective  avionics  systems. 

t 

This  Facility /Capability  Manual  for  the  simulation  facilities  of  AF.VL  has  been 
developed  as  a means  for  increasing  the  effectiveness  of  these  important  technical  resources. 

The  primary  objwlive  of  this  manual  is  to  document  the  total  simulation  capability  in  a 
. manner  which  will  serve  several  groups; 

1.  Tho.M'  members  of  the  AFAL  directomte  charged  with  planning  or  approval  of  the 
simulation  facilities. 

2.  Potential  users  with  a lUM'd  to  understand  the  general  capabilities  and  limitations  of 
the  simulation  facilities. 

d.  .Vctual  users  of  the  facilities  with  a new!  to  plan  simulations,  document  input  data, 
conduct  or  coonlinate  simulations,  and  interpret  results. 
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4.  Members  of  the  AFAL  staff  who  are  involved  in  updating,  enlarging,  or  deleting 
simulation  capabilities. 

A secondary  objective  of  this  manual  is  to  document  the  relationships  between  the 
\arious  facilities,  which  may  enhance  their  interaction  and,  thus,  improve  the  cost- 
effectiveness  of  the  overall  AFAL  simulation  capability. 

The  manual  achieves  these  objectives  by  presenting  introductory  and  summary  material 
in  section  I and  by  presenting  more  detailed  descriptive  material  in  subsequent  sections.  The 
contents  of  section  1 address  the  laboratory  capabilities  from  a planning/management  view- 
point by  relating  the  laboratory  mission  to  present  facility  capability  through  the  develop- 
ment of  a conceptual  simulation  class  structure.  The  contents  of  subsequent  sections  of  this 
manual  address  specific  facility/capability  from  a potential-user  viewpoint.  Both  hardware 
and  software  availability  are  documented.  The  technical  level  of  these  sections  is  such  that 
available  capability  can  be  determined  and  some  insight  can  be  gained  regarding  user 
interface.  For  more  detailed  simulation  facility  capability  and  utilization,  the  reference 
documentation  should  be  consulted. 
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Each  of  the  divisions  within  AFAL  has  been  assigned  a major  section  heading  within  the 
manual  organization.  Thus,  section  II  describes  the  capability/facility  resident  within  the 
Systems  Avionics  Division;  section  III  those  within  the  Electronic  Technology  Division; 
section  IV  those  within  the  Electronic  Warfare  Division;  and  section  V those  within  the 
Reconnaissance  and  Weapon  Delivery  Division.  Because  of  time  and  funding  constraints 
under  the  current  contract,  the  extent  of  the  manual  has  been  limited  to  the  simulation 
facilities  within  the  Systems  Avionics  Division.  It  is  anticipated  that  the  manual  will  be 
expanded  in  the  future  to  include  the  remaining  AFAL  Divisions. 

1.1  AIR  FORCE  AVIONICS  LABORATORY:  MISSION  AND  ORGANIZATION 

The  Air  Force  Avionics  Laboratory  is  the  principal  development  organization  within  Air 
Force  Systems  Command  (AFSC)  for  new  avionics  technology.  The  primary  responsibility 
of  AFAL  is  to  provide  the  USAF  with  the  products  and  expertise  required  for  the  acquisi- 
tion of  the  best  possible  avionics  systems.  To  meet  this  responsibility,  AFAL  maintains  a 
base  of  avionics  technology  and  develops  and  demonstrates  cost-effective  avionics  systems 
and  subsystems  to  improve  operational  capabilities  in  navigation,  communications,  elec- 
tronic warfare,  surveillance,  reconnaissance,  and  weapon  delivery.  As  required,  the  labora- 
tory provides  technical  assistance  in  the  systems-acquisition  process  to  all  elements  of 
AFSC,  and  to  all  USAF  elements  in  the  operation  and  modification  of  avionics  equipment 
in  the  inventory. 
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riu*  laboratory  is  ornanized  into  four  major  tochnoloj^’  nf^iips,  as  shown  in  the 
i>r>;anuation  ihart  in  Fij!\ire  l.l-l.  System  and  device  development  is  conducted  in  the 
Systems  Avionics,  Keconnaissance  luid  Weapon  Delivery,  Klectronic  Technoloi!>'.  and 
Klectronic  Warfare  Divisions,  The  mission  of  each  of  these  is  discussed  briefly  in  the 
followinn  paragraphs. 


AFWAL  COMMANDER 


Fi|urt  1.1-1.  AFAL  orfiniMtion. 


1.1.1.  Systems  Avionics  Division:  Mission 

The  Systems  Avionics  Division  develops  concepts  and  methodology  for  the  architecture 
of  advancer!  avionics  systems.  Research  and  exploratory  development  are  conducted  in  the 
areas  of  information  handling,  processing,  and  transfer;  display  and  control;  subsystem 
design  and  optimization;  subsystem  and  functional  integration;  and  electromagnetic  trans- 
mission links.  Programs  within  the  Division  develop  and  demonstrate  advanced  concepts  of 
avionics  subsystems  integration,  automation,  and  information  processing,  display,  control, 
and  transfer.  In-hou.st'  capability  is  being  developed  to  define,  demonstrate,  and  test  digital 
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avionics  and  to  provide  the  hot-bench  facility  and  expertise  necessary  to  achieve  this  capa- 
bility. The  Digital  Avionics  Information  System  (DAIS)  is  an  example  of  such  a program. 

1.1.2  Electronic  Technology  Division:  Mission 

The  Electronic  Technology  Division  maintains  centers  of  excellence  in  radar  and  micro- 
wave  technology,  laser  and  electro-optic  technology,  and  microelectronics.  The  Division 
conducts  basic  exploratory  research  and  advanced  development  programs  in  these  areas  to 
support  the  needs  of  AFAL  and  its  application  divisions.  In  the  area  of  microwave  technol- 
ogy, program  objectives  include  identification  and  development  of  the  technology'  of  micro- 
wave  avionics  devices,  sensors,  and  systems  to  improve  their  performance,  reduce  their  costs, 
and  evaluate  alternative  development  paths.  The  Division  seeks  to  expand  the  electro-optic 
component  technology  base,  providing  new  devices  to  support  a wider  range  of  applications, 
as  well  as  offering  solutions  to  Air  Force  requirements.  In  the  microelectronics  field,  obje( - 
tives  associated  with  reduced  cost  of  ownership,  increased  performance  and  reliability,  eaise 
of  maintenance,  and  increased  ability  to  withstand  stringent  operating  conditions  are  pur- 
sued by  recognizing  and  exploiting  emerging  concepts  and  technologies  to  assure  rapid 
transition  of  new  devices  and  circuits  into  the  Air  Force  inventory.  Materials,  such  as  III-IV 
compounds  and  heterogeneous  structures,  which  show  promise  for  advanced  signal- 
processing applications,  are  explored,  as  well  as  specific  materials  applications,  such  as 
bubble  memories. 

1.1.3  Electronic  Warfare  Division:  Mission 

The  Electronic  Warfare  Division  conducts  exploratory  and  advanced  development  pro- 
grams in  the  technical  domain  of  electromagnetic  warfare.  The  Division  participates  in 
advanced  planning  to  provide  effective  guidance  for  the  Division  mission  and  to  provide 
timely  transition  of  exploratory  and  advanced  development  programs  into  effective  military 
h2irdware.  In  carrying  out  its  mission,  the  Division  maintains  electronic  simulators,  such  as 
the  Electronic  Defense  Evaluator  (EDE)  and  the  Dynamic  Electromagnetic  Environment 
Simulator  (DEES).  Technical  areas  of  interest  include,  among  others:  analysis  of  threats, 
projecting  scenarios,  modeling  the  effects  of  electronic  warfare  on  penetration  effectiveness, 
and  performing  tradeoff  evaluations;  performance  of  electronic  warfare  technique  analysis 
to  generate  EW  effectiveness  data;  development  and  demonstration  of  the  military  worth  of 
countermeasures  for  defense  of  aerospace  vehicles  against  threats  utilizing  optical  or  elec- 
tro-optical guidance  or  fire  control  systems;  and  development  of  advanced  techniques,  tac- 
tics, and  equipments  for  manned  aircraft  to  penetrate  or  enter  a hostile  air  environment. 
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1.1.4  Reconnaissance  and  Weapon  Delivery  Division:  Mission 

The  Reeonnai.ssance  and  Weapon  Delivery  Division  conducts  exploratory  and  advanced 
development  programs  to  demonstrate  improved  aerospaceborne  reconnaissance,  navigation 
and  weapon  delivers’  capabilities  for  present  and  future  Air  Force  tactical  and  strategic 
weapon  systems.  The  Division  conducts  studies  and  analyses  of  potential  concepts,  sub- 
system reiiuirements,  aerospaceborne  reconnaissance,  navigation,  target  acquisition,  fire  con- 
trol and  weapon  delivers'  avionics  subsystems,  and  provides  promising  completed  explora- 
tory efforts  for  incorporation  into  those  subsystems.  .Another  Division  function  is  identifica- 
tion of  areas  of  technology-  in  its  luea  of  interest,  which  require  development  by  other 
.•\F.\L  organizations.  .Also,  the  Division  maintains  a group  for  dynamic  mobile  evaluation  of 
softwiu'e  for  aerospace  inertial  reference  subsystems  and  a group  for  dynamic  and  environ- 
mental evaluation  of  avionic  sensors,  subsystems,  and  systems. 


1.2  SIMULATION  CLASS  STRUCTURE 

In  the  .same  .sense  that  avionic  harilware  development  tends  to  proceed  within  the 
narrow  confines  of  the  function.s  and  performance  of  specific  subsystems— for  example,  a 
radar  or  voice  communication  radio— simulation  capabilities  also  tend  to  be  developed  for 
aid  m design  of  certain  specific  subfunctions  of  avionics.  In  recent  years,  however,  the 
opportunity  for  and  desirability  of  the  integration  of  avionics  subsystems  into  a functional 
hardware  system  have  presented  the  necessity  to  examine  the  tradeoffs  required  by  the 
.system-integration  process. 

While  the  simulation  capabilities  that  are  a vital  part  of  subsystem  design  are  as  neces- 
sary as  ever,  simulation  of  systems  at  a higher  aggregate  level  become  equally  important.  In 
fact,  a hierarchy  of  simulation  capabilities  becomes  desirable  and  necessary  to  insure  that 
overall  system  performance  meets  mission  requirements  and  that  each  subsystem  satisfies  its 
own  subrequirements.  When  simulation  is  viewed  from  the  perspective  of  assessing  the  total 
avionic  function  as  an  integrated  system,  it  is  convenient  to  structure  it  to  parallel  a top- 
down-system  design  procedure  that  results  in  maximizing  total  system  performance. 

This  section  presents  a conceptual  simulation  architecture  encompassing  several  levels  of 
simulation  support  related  to  the  avionics  design  and  integration  process.  The  rationale  for 
this  architecture  was  originally  developed  for  the  Avionic  System  Analysis  and  Integration 
Laboratory  (AVSAIL)  facility  (Section  1.3.1)  in  the  Systems  Avionics  Division.  However, 
the  architecture  is  designed  to  encompass  a total  system  approach  to  simulation  of  avionics, 
rather  than  a subsystem  approa<  h,  .so  that  it  is  a useful  framework  for  relating  the  function 
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of  sinuilatioo  fai'ilitios  capalulities  in  other  AFAL  Divisions  as  well.  As  may  heeome  appar- 
ent, such  a class  structure  must  occasionally  he  warped  slightly  to  fit  an  individual  case,  hut 
111  K‘*i’t*ral  It  provides  a useful  framework  for  both  laboratory  manaj'ement  and  user.  By 
categorically  locating  given  simulation  capability  within  such  an  architecture,  it  makes  it 
convenient  for  facility  management  to  plan  for  controlled  e.xpansion  of  capability  and  also 
for  the  potential  u.ser  to  select  and  review  only  those  capabilities  which  are  relevant  to  the 
simulation  iletail  recpiireil  for  his  particular  system  ilesign  task.  These  categories  are  listed 
lielow  in  Table  1.2-1.  Table  1.2-2  shows  applications,  outputs,  and  e.xamples  of  the  various 
levels  as  configuriHl  at  the  .-Vvionics  Laboratory. 
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TABLE  1.2  1.  SIMULATION  LEVELS 


Level  I - System  lunctional  Level  V - Real-time  dynamic 

Level  II  - Discrete  event  Level  VI  - Real  time  sensor  signal  level 

Level  III  - Scientific  Level  VII  - Special  purpose  hybrid 

Level  IV  - Interpretive  computer 


The.sp  various  simulation  categories  may  operate  as  separate  capabilities  for  designers 
whose  problems  fit  a particular  level,  or  where  evaluation  is  needed  of  a specific  proposed 
configuration.  The  designer  may  also  use  the  I'ategories  as  a continuous  system  of  levels 
starting  at  the  broad  view  and  proceeding  to  finer  levels  of  detail.  Iteration  may  occur 
among  any  of  the  levels  at  any  point  in  the  simulations. 

.-\t  the  broadest  level  of  Systems  Simulations,  the  designer  looks  at  functions  and  ob- 
tains general,  variable,  probabilistic  outputs.  At  Discrete  Event  Simulation,  the  e.xterior 
Innindaries  of  the  proposed  system  become  more  specific.  .-Vt  this  level  the  designer  gains  an 
understanding  of  what  the  hardware  in  the  proposed  system  would  look  like  and  how  the 
subsystems  would  interconnect  and  communicate.  In  Scientific  Simulation,  the  software  is 
addl'd  in  the  form  of  algorithms,  and  the  entire  system  is  placed  inside  an  external  environ- 
ment model  group  so  that  flight  conditions  may  he  reproduced.  In  Interpretive  Computer 
Simulation,  the  subsystem  algorithms  would  be  changed  to  actual  flight  codes.  In  Real-Time 
Dynamic  Simulation,  an  actual  subsystem  interconnects  with  the  simulation  and  replaces  a 
mixlel.  Most  of  the  proposed  avionics  system  would  continue  to  be  in  modeled  form  since 
this  test  concerns  the  integration  and  interface  of  a single  subsy,stem.  In  Real-Sensor  Signal 
Level  Simulation,  groups  of  functional  hardware  would  replace  groups  of  models  for  a 
complete  system  integration  test.  The  external  environment  rem^ains  modeled  and  inter- 
faced. but  actual  sensors  may  also  be  stimulated  to  carry  the  environmental  .simulation  to 
ftirther  details. 
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TABLE  1.2  2.  SIMULATION  CLASSES 


^ ClasMt 

Applications 

Outputs 

Examples  ! 

“ ■ ■ 

1.  System  Functional 

1 

1 

System  Analysis 

System  Design 

System  Requiremaius 
Definition 

System  Level  Trade 

Studies 

Parametric  Analyses 

Performance 

Parameters/ Limits 
Sensitivity  Thresholds 
Criteria  Requirements 
Mission  Scenarios 

System  Reliability 
Estimates 

AEP  j 

Cost  Models  ! 

1 

II.  Discrete  Event 

Computer  System 
Capabilities 

Throughput  Analyses 

I/O  Requiiements  Loading 
Information  Transfer 
Requirements  Loading 
Benchmark  Testing 

System  Time  Line  Analysis 

Processing  Requirements 
CPU  Siting 

Bus  Loading 

System  Level  Timing 

Simnuc 

DPM 

GASP  IV 

III.  Scientific 

Navigation/Sensor/Flight 
Dynamics  Interactions 
Algorithm  Verification 
System  Performance 
Evaluation 

Subsystem  Design 

Closed  Loop  Navigation 
Operation 

Ideal  Weapon  Del. 
Evaluation 

Statistical  Data  Collection 
Processor  Characteristics/ 
Design 

Mux  System  Design 

System  Software  Develop- 
ment 

SDVS 

AVSIM 

i 

IV.  Interpretive 

Computer 

Detailed  Timing  Evaluation 
Fine  Grain  System  Inter- 
action 

Flight  Computer  Code 
Evaluation 

Detailed  Design  of  Proc- 
essor/Mux Subsystems 

Detailed  Timing  of 
Command/Oiscretes 
Detailed  "Debug"  Aid 
for  Flight  Code 
Preliminary  Hardware 
Timing  Evaluations 

SDVS  (ICS) 

Processor 

Architecture  (ISP) 

V.  Real-Time 

Dynamic 

Man-In-Loop  Evaluations 
(cockpit  only) 

OFP  & Flight  Computer 
Interaction 

Functional  Avionic 
Representation 

Mission  Scenario 

Evaluation 

Sensor  Modeling  Verifi-. 
cation 

Control/D isplay  Evalu- 
ation 

Phase  IV  &V  of  OFP 
OFP/Flight  Computer 
Integration 

AVSIM 
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VI.  Real'Timt  S<nsor 

1 Signal  Laval 

System  Inlcfration 
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Intertece  Veirfication 
Integrated  System 

Testing 

Dynamic  Simulation 

T esting  of  Sensors 

End-to-End  Signal  Flow 
Testing 

Hardwart/Software 

Dynamic  Inter- 
Ktion 

Completely  Instrumented 
Integrated  System  Tests 
Phase  IV  & V ot  OFP 

DAIS 

! 

VII.  Special  Purpose 
j Hybrid 

L 

A-J  Signal  Structures 

Les  8/9  Support 

GPS  Support 

RPU  Data  1 mk  Design 

Verified  A-J  Signal 
Structures 

Performance  vs.  Channel 
Characteristics 

CSEL 

i 
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riu'st'  siiiuilatioii  K'vt'ls  avi'  (lisnisst'tl  iiulivulually  ami  in  uroati'v  liotail  in  tin-  fnlhnvin^ 
paranraplis. 

1.2.1  Level  I,  System  Functional  Simulations 

System  sinuilations  are  a starting;  (loint  for  defining;,  in  system  terms,  the  avioihi-  fime- 
tions  needed.  In  a eompnter  simulation  of  the  funetional  eajialhlities  of  an  avionies  system, 
analy.ses  of  the  many  options  available  provide  the  systems  designer  with  a means  of  ileter- 
1'  ninn  the  optimum  avionies  eonfiuuration  for  a selected  mission.  Mission  requirements  are 
first  analyzed  and  allocated  to  specific  functions  and  modes  of  operation  for  each  phase  of 
each  postulated  mission.  .Appropriate  Irardware  eon fiijurat ions  an*  then  ilefinetl,  ami  (he 
operaling  characteristics  specified  to  create  a system  simulation  model.  .A  compub'r  analysis 
IS  then  made  to  evaluate  the  performance  of  each  confiituration  relative  to  various  mission 
n'quirenienis.  Overall  mission  performance,  as  well  as  candidate  .system  cost-effectiveness, 
an'  elements  of  such  an  analysis. 

Typically,  the  system  designer  defines  the  charaeteristies  applicable  to  the  desired  air- 
craft type  and  avionics  system  eonfiuuration;  then  he  selects  the  mathematical  models 
necessary  to  accomplish  the  simulation  from  .WSAlL’s  library  of  simulation  software.  He 
may  then  successively  modify  the  confitiuration  by  deletinu  or  addinu  various  subsystem 
models. 


Comparision  of  the  simulation  runs  and  the  system  performance  requirements  will  sug- 
gest tradeoffs,  which  could  result  in  modifying  the  initial  system  design.  These  modified 
configurations  may  then  be  subjected  to  additional  simulation  analysis. 

The  system  designer  may  vary  numerous  model  characteristics  and  determine  the  effect 
of  the  changes  on  overall  system  performance.  He  may  utilize  various  configurations  to 
examine  the  operation  of  each  avionics  subsystem  and  gain  an  understanding  of  the  func- 
tional performance  necessary  to  insure  that  the  system  is  responsive  to  primary  mission 
requirements.  Thus,  with  AVSAlL’s  capabilities,  the  .system  designer  can  examine  the  ef- 
fects of  varying  the  system’s  configuration  in  a logical  and  orderly  manner,  prior  to 
construction  of  hardware  prototypes.  In  general,  this  level  of  simulation  explores  and  com- 
pares different  modes  and  options  for  implementing  the  mission  functions.  Hundreds  of 
simulated  missions  can  l)e  examined  in  a few  minutes.  Once  mission  functions  have  been 
established,  further  refinement  of  the  system  design  may  lie  accomplished  with  more  de- 
tailed levels  of  simulation. 

1.2.2.  Level  II,  Discrete  Event  Simulations 

Discrete  eveiu  simulations  are  used  to  investigate  the  functional  and  physical  configura- 
tions of  a proposed  avionics  system  and  provide  analysis  of  information-processing  loads  and 
transfer  requirements.  The  designer  is  able  to  evaluate  and  analyze  time  sequences  and  the 
effects  of  .system  ilegradation.  He  looks  at  the  proposed  system  configuration,  and  he  can 
make  comparisons  of  various  configurations. 

Given  a specific  configuration  of  avionics  subsystems  and  the  detailed  performance 
requirements  of  each,  the  simulation  defines  the  capability  required  of  the  airborne  pro- 
ce.ssor  and  determines  the  flow  of  information  between  each  of  the  subsystems.  An  analysis 
of  the  amount  of  information  flow  at  any  given  point  in  time  provides  data  on  gross  system 
timing  and  enables  the  designer  to  reallocate  functions  as  necessary. 

The  simulation  also  permits  examination  of  the  information-processing  cycle  for  the 
avionics  system  by  relating  each  operation  to  airborne  processor  time  for  comparision  with 
established  time  lH)undaries.  For  each  function,  the  designer  can  determine  total  lime  used, 
including  processing  time  required  or  processor  speed  required  for  desired  performance. 
.Accuracy  requirements  may  also  be  analyzed. 

V'arious  methods  of  interconnecting  sub.systems  can  be  examine<l.  The  simulation  fvr- 
mits  examination  of  trial  subsystem  interconnections  to  determine  the  information  flow 


timing.  The  desitiner  thus  identifies  peak  loading  conditions  and  excessive  information  de- 
lays. 

The  simulation  also  establishes  boundaries  on  the  amount  of  information  flow  between 
any  subsystem  and  any  processor  or  termination  point  at  any  given  time.  This  rt>sults  in  the 
questions;  What  .shouhl  be  allocated  to  an  airborne  central  proces.sor?  What  proce.s.sing 
should  be  broken  up  and  allocated  to  local  points  in  the  system? 

If,  after  trying  partitioning  alternatives,  the  simulation  re.sult  calls  for  impractical  air- 
borne processor  capacity  or  speed,  then  the  proposed  avionics  system  may  not  lie  a valid 
solution  for  the  mussion  in  terms  of  current  hardware  technology.  However,  this  typi>  of 
result  would  suggest  the  need  to  iterate  with  the  .system  functional  simulation,  trying  other 
modes  and  configurations.  Feedback  and  interaction  among  various  types  of  simulation  is  a 
conventional  usage  of  AVSAIL  in  design  and  analysis. 

The  proposed  partitioning  may  or  may  not  be  satisfactory;  if  not,  modification  or 
reconfiguration  is  necessary.  The  designer  continues  to  experiment  with  various  ways  in 
which  the  system  can  be  interconnected.  W'hen  he  has  modeled  a workable  system,  he  has 
defined  the  hardware  in  terms  of  operating  characteristics,  hardware  interconnection,  and 
information  flow.  He  has  also  examined  information  flow  rates  and  has  established  general 
boundaries  on  the  amount  and  speed  of  airborne  processing  required.  His  next  step  is  to 
model  in  detail  all  the  elements  of  the  system. 

1.2.3  Level  III,  Scientific  Simulations 

Scientific  Simulations  involve  the  use  of  detailed  models  for  both  hardware  and  software 
in  a proposed  avionics  system.  This  level  provides  an  opportunity  for  comprehensive  evalua- 
tion of  the  proposed  system’s  operating  logic,  performance,  and  timing,  and  permits  exami- 
nation of  tradeoffs  between  hardware  and  software.  The  physical  partitioning  of  the  pro- 
posed system  is  validated,  and  hardware  specifications  and  software  algorithms  are  devel- 
oped. 

The  detailed  mathematical  models  of  specific  subsystems  are  constructed  to  include 
functional  performance  and  to  accept  input  and  produce  output  signals.  For  example,  a 
chosen  model  of  an  inertial  subsystem  would  produce  signals,  which  would  correspond  to 
the  velocities  it  should  sense  over  a particular  period  of  time  during  a simulated  mission. 

The  mathematical  models  are  combined  with  a detailed  information-transfer  scheme  and 
with  trial  software  models;  the  entire  simulation  is  also  embedded  within  environmental 
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nuulels.  The  c M environmental  simulation  ineludes  validated  models  of  airframe, 
rotating  earth  and  atmosphere  so  that  the  system  under  test  ean  receive  realistic  signals  and 
produce  results  that  can  be  accurately  analyzed  for  functional  performance. 

.\side  from  a close  h)ok  at  hardware  elements  and  partitioning,  .software  development 
for  the  proposed  avionics  system  is  begun  in  Scientific  Simulation  by  providing  an  operating 
environment  to  try  algorithms  in  dynamic  situations.  The  designer  can  then  evaluate  the 
performance  of  a particular  navigation  algorithm  under  given  conditions. 


Since  the  .system  elements  are  modeled  in  detail  and  accept  realistic  inputs,  the  simula- 
tion also  provides  accurate  outputs  in  the  form  of  actual  signal  levels.  After  suitable 
algorithms  are  tested  and  potential  hardware/software  tradeoffs  are  identified  and  chosen, 
detailed  specification.-,  are  generated  for  both  hardware  and  software. 


1.2.4  Level  IV,  Interpretive  Computer  Simulations 

Interpretive  Computer  Simulations  are  similar  to  Scientific  Simulations,  but  software 
analysis  is  performed  at  the  airborne  processor  instruction  level  for  detailed  flight-program 
development  and  an  examination  of  fine-grain  hardware  and  software  interactions.  The 
timing  of  all  airborne-processing  functions  is  recorded  for  analysis. 

The  Scientific  Simulations  examine  various  airborne  software  algorithms  operating  with 
detailed  models  of  the  hardware  and  the  environment.  At  the  Interpretive  Computer 
Simulation  level,  the  simulations  examine  complete  airborne  software  coding,  operating 
with  similarly  detailed  models  of  hardware  and  environment.  A compiler  in  the  simulation 
computer  generates  the  machine  code  so  that  the  model  of  the  airborne  processor  can 
operate  with  bit-by-bit  simulation  of  each  machine-level  instruction.  Feedback  with  other 
types  of  AVSAIL  simulation  may  be  required  to  refine  the  software  coding. 

Since  the  analysis  is  very  detailed,  the  simulation  is  focused  at  critical  processing  points 
in  the  mission,  examining  short  segments  of  airborne  processor  operation.  Several  hours  of 
simulation  are  typically  required  to  evaluate  a few  minutes  of  flight  time. 

Actual  execution  of  flight  code  instructions  provides  a thorough  analytical  method  for 
evaluation  of  software  accuracy  and  identification  of  timing  problems.  The  most  common 
objective  of  this  simulation  is  to  support  the  development  and  validation  of  flight  code. 
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1.2.5  Level  V,  Real-Time  Dynamic  Simulations 


I The  primary  purpose  of  Real-Time  Dynamic  Simulation  is  to  test  actual  hardware 

operating  in  real  time  with  accurate,  detailed  simulation  models  of  the  proposed  avionics 
' ; system  and  the  environment. 

! 

I Any  actual  avionics  subsystem  may  be  exercised  to  examine  its  real-time  interactions 

with  the  total  avionics  system.  This  level  of  simulation  is  used  to  support  integration  of  the 
particular  subsystem  with  the  proposed  avionics  system.  For  example,  an  airborne 
processor,  loaded  with  the  flight  code  it  will  run,  can  be  driven  by  the  simulation.  Inputs 
would  be  provided  to  the  airborne  processor  hardware  by  the  simulation  models.  The 
models  would  also  accept  outputs  from  the  hardware  under  test  and  interact  realistically 
with  the  system. 

The  environmental  simulation  provides  the  hardware  under  test  with  a realistic  operating 
I environment,  including  all  flight  information  references.  A comprehensive  example  is  the 

I operation  of  a cockpit  with  controls  and  displays  hardware,  either  to  examine  the  hardware 

i interfaces  and  interactions  with  the  rest  of  the  avionics  system  or  for  a man-in-the-loop 

j study.  The  simulation  will  accept  the  control  inputs  and  drive  the  displays  according  to 

model  outputs,  including  the  environment  simulation.  A video  scanning  and  mixing 
, capability  provides  realistic  display  background  synchronized  with  the  modeled  airframe 

. and  environment.  The  sampling  of  controls  and  the  driving  of  displays  occur  in  real  time  at 

• the  cycle  time  of  the  proposed  avionics  system. 

I 

i 

Except  for  such  questions  as  the  effect  of  dynamic  maneuvering  loads,  Real-Time 
j Dynamic  Simulation  can  produce  avionics  system  debugging  results  previously  obtainable 

only  through  expensive  and  time-consuming  flight  test.  For  this  level  of  simulation,  actual 
hardware  replaces  one  or  more  simulation  models  for  validation  of  one  subsystem  at  a time. 

1.2.6  Level  VI,  Real-Time  Sensor  Signal  Level  Simulations 


Real-Time  Sensor  Signal  Level  Simulations  are  the  basic  tool  for  total  system 
integration.  Groups  of  simulation  models  such  as  those  used  in  Real-Time  Dynamic 
Simulation  would  be  replaced  by  multiple  functional  groups  of  actual  hardware  run  together 
in  real  time  for  an  integrated  study.  Whereas  Real-Time  Dynamic  Simulations  concentrate 
on  a single  item  or  a single  closely  related  group  of  hardware,  this  integrated  simulation  level 
exercises  and  examines  complete  functional  sets  of  hardware  subsystems.  For  example,  all 
hardware  which  will  operate  on  information  transfer  and  processing  may  be  tested  together. 
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A complete  external  environment  is  simulated  to  the  avionics  system  under  test,  and  the 
AVSAIL  simulation  computer  is  capable  of  providing  appropriate  stimulation  to  actual 
sensors  so  that  overall  performance  of  the  system  may  be  evaluated  dynamically  and 
realistically.  Where  it  is  not  practical  to  present  a computer-generated  signal  to  an  actual 
sensor  (for  example,  where  aircraft  motion  must  be  detecUnl),  the  sensor  output  is  modeled 
to  conform  with  the  missions  and  mission  environments  being  evaluated.  Modeled  signals  are 
mjecU'd  as  early  in  the  system  test  as  is  practical. 

Complete  groupings  of  hardware  are  operated  in  a simulated  real-time  mission  to  study 
integrated  performance,  to  verify  that  all  hardware  interfaces  openite  properly,  and  to 
validate  the  system  software  under  simulated  flight  conditions.  Virtually  all  mission  modes 
can  be  examuuHl  using  validated  models  of  earth,  atmosphere,  and  airframe. 

.■\VS.\1L  complete  system  integration  tests  complement  flight  testing,  particularh’  in 
software  validation  and  hardware  debugging.  These  simulations  can  replai'e  such  basic 
checkout  proeixhires  previously  accomplished  only  in  flight  testing;  subsequent  flight  tests 
can  concentrate  on  validating  ilynamic  performance. 

1.2.7  Level  VI  I,  Special  Purpose  Hybrid 

While  not  necessarily  a “level”  per  se.  the  capability  to  perform  special  purtiose 
simulations  is  a necessary  requirement  in  systems  ilcsign.  Under  the  Spwial  Purpose 
categorv’.  the  .Avionics  Laboratory  has  developed  the  Communications  Systems  Kvaluation 
l..;iboratory  (CSEL). 

CSEL  has  been  developed  to  assist  the  U.S.  .Air  Force  in  the  analysis,  synthesis,  and 
modeling  of  its  communications  and  data  links,  and  to  provide  a cost-effective  means  for 
dynamic  evaluation  and  comparison  of  advanced  techniques  and  systems. 

Current  Air  Force  communications  links  between  aircraft— both  direct  and  via 
.satelliU>— operate  in  the  ultra  high  frequency  (UHF)  or  super  high  frequency  (SHF)  radio 
bands.  .As  new  user  requirements  evolve,  new  communications  systems  and  data  links,  such 
as  the  Lincoln  Laboratories’  LES  8/9  satellites,  are  being  designed  to  handle  them.  However, 
new  systems  and  innovative  equipment  are.  in  themselves,  not  enough  to  handle  the 
ever-increasing  user  requirements;  there  is  a corn'sponding  need  for  change  in  such  related 
areas  as  frequency  bands  of  operation,  signal  structures,  and  modulation  techniques.  The 
CSEL,  by  providing  the  proper  computer  hardwan'/software  mix,  offers  a dynamic 
evaluation  tool  that  will  provide  the  capability  to  observe  and  evaluate  the  performance  of 
such  advanced  communications  and  data  systems. 


1.2.8  Digital  Avionic  Information  System  (DAIS) 


The  various  levels  of  simulation  resident  within  AVSAIL  allow  the  user  not  only  to 
select  the  appropriate  degree  of  sophistication  to  satisfy  his  application,  but  more 
powerfully,  to  assemble  various  levels  in  order  to  broaden  interactively  the  available 
simulation  capability.  Additionally,  the  user  may  choose  to  sequentially  select  various 
simulation  levels  as  he  moves  through  the  various  phases  of  system  design.  In  the  following 
discussion,  the  DAIS  project  is  presented  as  an  example  of  the  manner  in  which  .W’S.AIL 
can  support  the  various  programs  resident  within  AFAL  by  virtue  of  this  simulation  level 
structure. 

The  purpose  of  the  D.AIS  project  is  to  demonstrate  a coherent  solution  to  the  problem 
of  proliferation  and  nonstandardization  of  aircraft  avionics,  to  develop  and  test  in  a 
hot-bench  configuration  (known  as  the  Integrated  Test  Bed)  the  DAIS  concept,  and  to 
permit  the  Air  Force  to  assume  the  initiative  in  the  specification  of  avionics  configurations 
for  future  .■Xir  Force  weapon  systems  acquisitions.  The  DAIS  design  approach  reflects  a total 
system  concept  that  is  functionally  oriented  rather  than  hardware  oriented. 

The  heart  of  the  D.MS  system  is  the  redundant  time  division  multiple.x  data  bus  shown 
in  Figure  1.2. 8-1.  This  bus  allows  information  from  the  aircraft  subsystems  (e.g.,  avionics 
units,  stores  management,  power  control)  interfaced  by  remote  terminals  (HI)  to  be 
communicated  along  the  bus  and  to  a set  of  shared  D.MS  processors  through  Bus  Control 
Interface  Units  (BCllI)  in  the  processors.  Mission  software,  developed  through  sinuilation 
with  the  Software  Design  and  Verification  System  (SDVS)  in  non-real-time  interaction 
(Levels  II  and  III)  with  aircraft  and  environmental  models,  can  be  exercised  in  real  time  in 
the  ITB  facility.  For  e.xample,  a pilot  flying  a simulated  cockpit  views  a simulated, 
computer-generated  scene  and  interacts  with  displays  in  the  cockpit  generati'd  by  D.-\1S 
mission  softw'are.  The  aircraft  external  environment  and  flight  dynamics  are  simulated  by 
models  executed  by  the  host  computer  in  a Class  11  simulation.  During  such  a simulated 
flight,  the  mission  software/processor  performance  is  monitored  by  the  Super  Control  and 
Display  Units  (SCADU),  while  the  bus  performance  is  monitored  by  the  Bus  Monitor  Unit 
(BMU).  The  results  of  the  Level  V simulation  can  then  be  compared  with  those  predicted  by 
earlier  non-real-time  simulations  at  Levels  I to  IV.  System  performance  is,  thus,  verified  in 
the  laboratory  instead  of  in  the  field.  Many  of  the  simulations  utilized  in  the  DAIS  1TB  have 
application  to  other  avionics  system  developments  and  are  described  in  Section  2.0  of  this 
manual. 
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SUPPORT  FACILITY  '5AIS 


Figure  1. 2.8-1.  Simplified  block  diagram  of  DAIS  ITB  facility. 


1.3  AFAL  FACILITIES 

The  hierarchy  of  facilities  for  simulation  at  the  Avionics  Laboratory  may  be 
j schematically  depicted  as  shown  in  Figure  1.3-1.  Major  laboratory  facilities,  such  as  the 

Dyniunic  .\nalyzer  Complex  (D.AC),  AVSAIL,  and  the  Electronic  Warfare  Simulation 
Facility  (EWSFl,  are  operated  by  .AFAL  divisions  and  constitute  laboratories  subdivided 

(essentially  by  generic  application.  Each  of  the  laboratories  has  varying  degrees  of  further 
division  into  component  facilities  and  capabilities,  as  for  example  is  illustrated  for  .WSAIL 
in  Figure  1.3-1.  The.se  major  components  may  be  utilized  in  various  configurations  to 
simulate  specific  systems  or  subsystems.  The  physical  facilities  of  the  AVS.ML  DFIC-IO  host 
compuU'r,  Picture  System,  Video  Center,  and  Cockpit  are  shown  in  conjunction  with 
AVSIM  D.MS  models  to  provide  a real-time  simulation  of  the  D.AIS  system.  .Alternatively, 
other  models  may  he  employed  by  .AVSIM,  along  with  dedicated  hardware  to  sinuilaU-  an 
F-lb  aircraft  fire  control  system. 

The  facilities  and  capabilities  of  the  Avionics  Laboratory  are  of  a complexity  and 
versatility  so  great  that  the  range  of  potential  applications  cannot  he  fully  described  in  a 
1.  manual  of  this  limited  extent.  It  is  rather  the  intent  here  to  describe  the  capabilities  and 

f facilities  themselves  so  that  the  user  may  himself  be  led  to  envision  the  applications.  The 

■ following  paragraphs  present  a brief  overview,  with  additional  details  provided  in  manual 

I sections  for  each  major  facility. 

1.3.1  Systems  Avionics  Division  (AVSAIL) 

1 

f 

The  AVSAIL  facility  has  been  configured  particularly  for  implementation  of  all  of  the 

1 

i;  simulation  classes  previously  described.  In  order  to  convey  the  flexibility  and  power  of  the 

j .AVSAIL  laboratory,  the  host  facility  is  described  in  the  following  sections.  The  scope  of  the 

jj  description  is  limited  to  those  aspects  of  the  facility  which  have  significance  to  the  conduct 

Ij  of  simulations,  rather  than  to  an  exhaustive  exploration  of  capability.  Discussions  of  the 

i basic  computer  and  peripheral  hardware  configuration,  the  operating  and  utility  software 

capabilities,  and  the  constituent  simulations  now  resident  in  AVSAIL  are  provided. 

1.3. 1.1  Hardware  Features 

The  AVSAIL  laboratory  is  structured  around  a Digital  Equipment  Corporation 
DECsystem-10  mainframe  computer.  As  depicted  by  Figure  1.3. 1.1-1,  the  DEC-10  has  a bus 
architecture,  which  provides  both  a memory  bus  for  processor-mert.ory  and  direct  memory 
access  communications  and  an  input/output  bus  for  processor-peripheral  communications. 
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A wide  ranne  of  poriphoral  input/output  deviees,  as  desi  ribod  subswiuently,  are  proviifed  to 
handle  bateh.  tiineshare,  and  rt'al-tinie  pro>;rani  development  and  exeeution  rec|uireinents.  A 
uiuqite  feature  of  the  AVSAIL  eonfiKuration  is  the  eijjht-ehannel  Direet  Memory  Aeeess 
(DMA)  capability  providtHi  for  access  by  a complement  of  ei^ht  PDP-11  series 
minicomputers.  The  PDP-ll’s  serve  to  interface  specific  simulations  {e.^..  Die  F-16  Fire 
('ontrol  Computer  simulator)  to  the  DEC-IO.  .An  overall  hardware  system  diaj>rani  is 
providtxl  in  Fixture  1.3. 1.1-1.  The  central  processing  unit  (CPU)  for  the  AV'S.AIL  DFC-10 
consists  of  dual  Kl-lO  processors,  with  the  confi^turation  beinj;  designatixi  as  a DEC-1077. 
Faich  CPL'  module  is  an  independent  processor,  and  pro^jrams  can  operate  in  parallel,  one 
pro^n'am  per  processor,  thereby  incri'asing  Uie  average  throujthput  speetl.  The  .-WS.AIL 
DEC-1077  memory  capacity  is  currently  four  ti-lk  word  modules  |DEC  MF  lOCi)  of  OoOns 
core  memor>’  and  512K  wortls  of  Ampex  .-\RM  lOLX  memory.  Word  size  is  36  bits  plus 
parity.  The  dual  Kl-10  processors  and  memory  modules  ;ire  directly  interfactxl  by  the 
memory  bus  of  the  DEC-IO,  allowing  maximum  utilization  of  memory  and  easy  expansion. 

Bulk  storage  is  available  on  both  multisurface  cartridge  disks  and  magnetic  tape.  All  disk 
and  tape  units  ;u:e  interfacetl  to  botli  the  I/O  bus  and  to  the  memory  bus.  The  system 
currently  provides  four  RP03  disk  drives  and  four  RP04  disk  drives.  Storage  capacity  of  the 
RP04’s  is  20. -18  million  wonis;  for  the  RP03’s,  the  capacity  is  one-half  that  of  the  RP04’s. 
The  available  magnetic  tape  drives  also  provide  a choice  of  performance.  Four  TV10.\-E 
nine-track  drives  operate  at  45  ips,  and  four  TV40  drives  operate  at  150  ips,  providing  a 
range  of  transfer  rates  from  9K  to  120K  characters  per  stvond. 

The  DEC-10  facility  provides  for  onsite  and  offsite  access  both  for  development  of 
software  and  for  its  execution.  Currently,  onsite  facilities  include  25  CRT  alphanumeric 
terminals,  two  local  CRT  graphic  display  U*rminals,  and  two  minicomputer-basiHl  data- 
acquisition  systems.  In  addition  to  these  physical  terminals,  the  DEC-10  monitor  software 
supports  up  to  48  virtual  terminals  or  '‘pseudoteletypes,’  which  allow  jobs  to  control  other 
jobs. 

Offsite  access  to  the  DEC-10  is  through  the  DC75  Data  Communications  System  (Figure 
1.3.1 .1-1),  which  provides  a maximum  of  eight  synchronous,  9,600  baud  lines.  Maximum 
aggregate  data  rate  is  30,000  bps.  Currently,  4,800-baud  full-duplex  leased  lines  connect  the 
AVSAIL  laboratory  through  this  interface  with  the  .Armament  Development  Center,  Eglin 
AFB,  Florida,  and  the  Naval  Weapons  Center,  China  Lake,  California. 

Two  line  printers  provide  high-spet>d  (1,250  line/min)  output  from  the  DEC-10.  C«nuihic 
hard-copy  output  is  available  from  a Calcomp  Model  563  plotter.  This  high-spetxl. 
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drum-type,  pen  and  ink  plotter  uses  31-inch  paper  and  operates  at  up  to  300  steps  per 
second.  Card  input  to  the  system  is  available  through  a 1,200-card-per-minute  reader. 


1.3.1. 2 Software  Features 


The  wide  variety  of  computing  requirements  demanded  by  the  several  classes  of 
simulations  carried  out  within  AVSAIL  are  satisfied  by  the  flexibility  and  scope  of  the 
DEC-10  software  package.  This  software  package  provides  for  the  concurrent  operations  of 
timesharing,  multistream  batch,  real-time,  and  remote  communications.  These  multifunction 
capabilities  allow  multiple  users,  both  at  AFAL  and  at  remote  locations,  to  perform  all  of 
the  tasks  necessary  to  create  new  simulations,  modify  existing  simulations,  and  run  those 
simulations  as  if  they  were  individual  users.  The  system  allows  a maximum  of  48  users. 


From  the  user’s  viewpoint,  the  DEC-10  may  be  thought  of  in  terms  of  (1)  input  device 
and  software  which  he  has  written  or  which  act  on  his  software,  as  in  Figure  1.3.1. 2-1;  (2) 
the  operating  system  software,  which  controls  system  resources;  and  (3)  the  system 
hardware  which  was  previously  described. 
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Figun  1.3.1. 2-1.  DECfTftem-10,  user's  view. 
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The  DEC-10  has  several  capabilities,  which  increase  the  utilization  of  system  resources  in 
a multiuser  environment.  First,  the  timesharing  capability  allows  resources  to  be  shared 
among  users.  Users  are  not  restricted  to  a small  set  of  system  resources,  but  instead  are 
provided  with  the  full  variety  of  facilities.  By  means  of  his  terminal,  the  user  has  online 
access  to  most  of  the  system’s  features.  This  online  access  is  available  through  the  operating 
system  command  control  language,  which  is  the  means  by  which  the  timesharing  user 
communicates  with  the  system. 

Through  the  command  language,  the  user  controls  the  running  of  a task,  or  job,  to 
achieve  the  desired  results:  create,  edit,  and  delete  files;  start,  suspend,  and  terminate  a job; 
compile,  execute,  and  debug  a program.  In  addition,  since  multiprogramming  batch  software 
accepts  the  same  command  language  as  the  timesliaring  software,  any  user  can  enter  a 
program  into  the  batch  run  queue.  Thus,  any  timesharing  terminal  can  act  as  a remote 
job-entry  terminal. 

With  the  command  language,  the  user  can  also  request  assignment  of  any  peripheral 
device  (magnetic  tape,  DECtape,  and  private  disk  pack)  for  exclusive  use.  When  the  request 
for  assignment  is  received,  the  operating  system  verifies  tliat  the  device  is  available  to  this 
user,  and  the  user  is  granted  its  private  use  until  he  relinquishes  it.  In  this  way,  the  user  can 
also  have  complete  control  of  devices  such  as  card  readers  and  punches,  paper-tape  readers 
and  punches,  and  line  printers. 

When  private  assignment  of  a slow-speed  device  (card  punch,  line  printer,  and  paper-tape 
punch,  and  plotter)  is  not  required,  the  user  can  employ  the  spooling  feature  of  the 
operating  system.  Spooling  is  a method  by  which  output  to  slow-speed  device  is  placed  on  a 
high-speed  disk  or  drum.  This  ttH^hnique  prevents  the  user  from  consuming  unnecessary  time 
and  space  in  core  while  waiting  for  either  a device  to  become  available  or  output  to  be 
completed.  In  addition,  the  device  is  managed  to  a better  degree  because  the  users  cannot  tie 
it  up  indefinitely,  and  the  demand  fluctuations  experienced  by  these  devices  are  equalized. 

Second,  the  DEC-10  has  the  capability  to  make  maximum  utilization  of  memory.  The 
DEC-10  is  a multiprogramming  system;  i.e.,  it  allows  multiple  independent-user  programs  to 
reside  simultaneously  in  memory  and  to  run  concurrently.  This  technique  of  sharing 
memory  and  processor  time  enhances  the  efficient  operation  of  the  system  by  switching  the 
processor  from  a program  that  is  temporarily  stopped  because  of  I/O  transmission  to  a 
program  that  is  exei-utable.  When  core  and  the  processor  are  shared  in  this  manner,  each 
user’s  program  has  a memory  area  distinct  from  the  area  of  other  users.  Any  attempt  to  read 
or  change  information  outside  of  the  area  a user  can  access  immediately  stops  the  program 
and  notifies  the  operating  .system.  Because  available  memory  can  contain  only  a finite 
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number  of  programs  at  any  one  time,  the  computing  system  employs  a secondary  memory, 
usually  disk  or  drum,  to  increase  the  number  of  users  serviced.  User  programs  exist  on  the 


f I secondary  memory  and  move  into  memory  for  execution.  Programs  in  memory  exchange 

! places  with  the  programs  being  transferred  from  secondary  memory  for  maximum  use 

i available  main  memory.  Because  the  transferring  or  swapping  takes  place  directly  between 

; main  memory  and  the  secondary  memory,  the  central  processor  can  be  operating  on  a user 

program  in  one  part  of  memory  while  swapping  is  taking  place  in  another.  This  independent, 
overlapped  operation  greatly  improves  system  utilization  by  increasing  the  number  of  users 

' that  can  be  simultaneously  accommodated. 

‘ To  further  increase  the  utilization  of  memory,  the  operating  system  allows  users  to  share 

the  same  copy  of  a program  or  data  segment.  This  prevents  the  excessive  memory  usage  that 
results  when  a program  is  duplicated  for  several  users.  A program  that  can  be  shared  is  called 
a reentrant  program  and  is  divided  into  two  parts  or  segments.  One  segment  contains  the 
I code  that  is  not  modified  during  execution  (e.g.,  compilers  and  assemblers)  and  can  be  used 

I by  any  number  of  users.  The  other  segment  contains  nonentrant  code  and  data.  The 

f operating  .system  provides  for  shared  segments  to  guarantee  that  they  are  not  accidentally 

I modified. 

I 

1 Third,  the  DEC-10  has  the  capability  to  manage  the  storage  of  user  program  and  data 

files  consistent  with  the  multiuser  environment.  The  mass  storage  devices  available  are 
shared  among  users,  and,  thus,  the  operating  system  must  insure  independence  among  the 
users;  one  user’s  actions  must  not  affect  the  activities  of  another  unless  the  users  desire  to 
work  together.  To  gueurantee  such  independence,  the  operating  system  provides  a file  system 
for  disks,  disk  packs,  and  drums.  Each  user’s  data  are  organized  into  groups  of  128- word 
blocks  called  files.  The  user  gives  a name  to  each  of  his  files,  and  the  list  of  these  names  is 
kept  by  the  operating  system  for  each  user.  The  operating  system  is  then  responsible  for 
protecting  each  user’s  file  storage  from  intrusion  by  unauthorized  users.  The  operating 

* system  leb  the  user  specify  protection  rights,  or  codes,  for  his  files.  These  codes  designate  if 
others  may  read  the  file,  and  after  access,  if  the  files  can  be  modified  in  any  way.  Files  are 

* assigned  protection  levels  for  each  of  the  three  classes  of  users;  self;  users  with  a common 
project  number;  and  all  users.  Each  user  class  may  be  assigned  a different  access  privilege,  so 
that  there  are  eight  levels  in  each  of  the  three  user  classes.  This  file  protection  scheme  results 

' in  a three-digit  access  code  for  all  files. 

1.?.1.3  Constituent  Simulations 


Within  AVSAIL  several  varied  simulations  are  resident  and  available  to  the  user.  These 
include.  Avionic  Evaluation  Program  (AEP);  a general,  event-driven  hybrid  system 
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simulation  program  (GASP  IV);  Distributed  Processor/Memory  System  Network  Simulation 
(DP/M  SNS);  Software  Design  and  Verification  System  (SDVS);  Avionic  System  Simulation 
(AVSIM);  Instruction  Set  Processor  (ISP);  and  the  Communication  System  Evaluation 
Laboratory  (CSEL).  These  simulations,  available  in  the  AVSAIL  laboratory,  provide  a 
generic  simulation  capability  applicable  to  all  phases  of  avionic  system  design  and 
integration.  The  nature  of  each  one  is  described  briefly  in  the  following  paragraphs.  More 
detailed  descriptions  are  given  in  other  sections  of  this  manual. 

1.3.1 .3.1  Avionics  evaluation  programs 

The  interactive  Avionics  Evaluation  Program  (AEP)  is  a collection  of  avionics 
performance-assessment  models.  AEP  provides  convenient  and  systematic  assessment  of 
avionics  in  the  mission  environment.  The  program  is  designed  to  be  flexible  and  easy  to  use 
with  emphasis  on  realistic  consideration  of  the  operational  environment  and  the  generation 
of  useful  data.  AEP  can  be  utilized  for  analysis  of  most  air-to-ground  and  air-to-air  missions. 
Individual  programs  contained  within  AEP  include  air-to-ground  and  air-to-mission  analysis, 
weapon-delivery  error  analysis,  target  acquisition  analysis,  and  a one-on-one  dogfight 
analysis.  These  programs  are  implemented  in  a conversational,  interactive  mode,  thus 
providing  a powerful  analytical  tool  available  to  users  by  means  of  dial-up  terminals.  They 
are,  therefore,  available  throughout  DOD  and  to  contractor  organizations  as  well. 

The  air-to-ground  mission  analysis  program  evaluates  the  performance  of  a flight  of  up 
to  four  aircraft  through  a specified  number  of  days  of  operation.  The  aircraft  proceeds  along 
an  externally  generated  nominal  trajectory  through  the  mission  phases  of  takeoff,  navigation 
to  the  search  area,  search,  attack,  and  return  to  base.  Consideration  of  ground  service 
requirements  is  included.  Monte  Carlo  techniques  are  applied  to  Mean  Time  Between  Failure 
(MTBF)  data  for  the  defined  avionics  throughout  the  mission  to  determine  which  subsystem 
modes  are  functioning,  resorting  to  backup  modes  and  mission  aborts  as  required. 

The  weapon  delivery  analysis  routine  is  a program  for  determining  the  distribution  of 
impact  errors  for  a weapon  system  utilizing  unguided,  unpowered  bombs.  The  routine  is 
capable  of  accommodating  almost  any  weapon  delivery  mechanization  under  the 
assumptions  of; 


1. 

2. 

3. 


Flat,  nonrotating  earth. 

Linear  transformation  of  component  error  sources  to  impact  er">rs,  and 
Normal  distribution  for  all  error  sources. 
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The  AEP  target  acquisition  model  is  a modified  version  of  the  Multiple  Airborne 
Reconnaissance  Sensor  Assessment  Model  (MARSAM  II).  MARSAM  II  models  the  sensor 
system  and  the  operational  environment  in  detail.  It  contains  models  for  displays,  lenses, 
filters,  and  film.  It  considers  the  impact  of  image  motion  compensation,  platform 
stabilization  errors,  backscattering,  and  atmospheric  effects  on  sensor  performance.  The 
human  observer  is  modeled  in  terms  of  ability  to  perceive  the  target  as  a function  of  size  and 
contrast,  display  signal-to-noise  ratio,  presence  of  confusing  objects,  and  time  in  the  field  of 
view.  Available  outputs  from  MARSAM  II  include  detailed  sensor  system  performance 
parameters  and  associated  probability  measures  of  detection,  recognition,  and  identification. 

The  air-to-air  AEP  analysis  program  is  a Monte  Carlo  simulation  of  two  opposing  aircraft 
flights  (up  to  four  aircraft  in  a flight)  through  an  entire  mission.  As  the  flight  progresses,  it  is 
influenced  by  hardware  failures,  refueling,  communications  to  airborne  or  ground 
controllers,  enemy  aircraft  detection  capability,  identification  requirements,  and  weapon 
capabilities.  When  one  side  detects  the  other,  that  flight  pursues  a course  directly  at  the 
other  flight  and  fires  when  the  weapon  constraints  are  satisfied.  The  encounter  is  considered 
only  until  both  sides  have  detected  the  other.  At  that  time,  the  relative  positions  and 
headings  are  stored  for  output  so  that  users  can  determine  which  side  has  the  relative 
advantage. 

A separate,  deterministic  air-to-air  program  permits  analysis  of  the  dogfight  encounter. 
It  simulates  an  engagement  between  two  fighter  aircraft.  The  logic  for  control  of  aircraft 
maneuvers  is  based  on  lag  pursuit  and  energy  management.  Lag  pursuit  implies  that  each 
aircraft  attempts  to  get  on  the  tail  of  the  other.  Energy  management  control  implies  that  the 
aircraft  seeks  a velocity  and  altitude  for  best  turning  performance. 

1.3. 1.3.2  GASP  IV  simulation  language 
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A simulation  language  provides  the  structure  and  the  terminology  to  facilitate  the 
building  of  simulations.  GASP  IV  is  such  a computer  language;  it  helps  the  user  to  build 
computer  simulation  programs  that  can  be  both  the  model  of  the  system  and  the  analysis 
vehicle.  Thus,  this  program  can  be  thought  of  as  a model  of  a system  and  as  a generator  of 
statistical  data  about  the  model  of  the  system. 

As  a programming  language,  GASP  IV  gives  the  computer  programmer  a set  of 
FORTRAN  statements  designed  to  carry  out  the  most  important  functions  in  simulation 
programming.  Modeling  concepts  are  translated  by  GASP  IV  into  FORTRAN  routines  that 
can  be  easily  used.  GASP  IV  has  five  distinct  features  that  make  it  particularly  attractive  as  a 
simulation  language: 


I 
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1.  GASP  IV  is  FORTRAN  based  and  requires  no  separate  compiling  system. 

2.  GASP  IV  is  modular  and  can  be  made  to  fit  on  all  machines  that  use  a FORTRAN 
IV  compiler. 

3.  GASP  IV  is  easy  to  learn  since  the  host  programming  language  is  usually  known,  and 
only  the  simulation  concepts  need  be  mastered. 

4.  GASP  IV  can  be  used  for  discrete,  continuous,  and  combined  modeling. 

5.  GASP  IV  is  easily  modified  and  extended  to  meet  the  needs  of  particular 
applications. 

Simulation  is  divided  into  two  categories:  discrete  change  and  continuous  change.  Note 
that  these  terms  describe  the  model,  not  the  real  system.  In  fact,  it  may  be  possible  to 
model  the  same  system  with  either  a discrete  change  (hereafter  referred  to  simply  as 
discrete)  or  a continuous  change  (continuous)  model.  GASP  IV  is  designed  to  accommodate 
both  categories  of  models,  separately  or  combined.  In  most  simulations,  time  is  the  major 
independent  variable.  Other  variables  included  in  a simulation  are  functions  of  time  and  are 
the  dependent  variables.  The  adjectives  discrete  and  continuous  refer  to  the  behavior  of  the 
dependent  variables.  Discrete  simulation  occurs  when  the  dependent  variables  of  the  model 
change  discretely  at  specified  points  in  simulated  time.  In  continuous  simulation  the 
dependent  variables  of  the  model  may  change  continuously  over  simulated  time.  In 
combined  simulation  the  dependent  variables  of  a model  may  change  discretely, 
continuously,  or  continuously  with  discrete  jumps  superimposed.  The  time  variable  may  be 
discrete  or  continuous. 

GASP  rV  is  a language  that  can  be  used  for  discrete,  continuous,  or  combined 
simulation.  In  GASP  IV  the  most  important  characteristics  of  combined  simulation,  which 
arise  from  the  interaction  between  discretely  and  continuously  changing  variables,  are  easily 
modeled.  In  general,  this  interaction  takes  one  of  three  forms.  First,  discrete  changes  may  be 
applied  to  “continuous”  variables.  Second,  achieving  specified  conditions  for  a state  variable 
may  cause  an  event  to  occur  or  to  be  scheduled.  Third,  the  functional  description  of 
continuous  variables  may  be  changed  discretely. 

GASP  rV  specifies  that  the  status  of  a system  be  described  in  terms  of  a set  of  entities, 
their  associated  attributes,  and  state  variables.  The  GASP  IV  simulation  philosophy  is  that  a 
dynamic  simulation  can  be  obtained  by  modeling  the  events  of  the  system  and  by  advancing 
time  from  one  event  to  the  next.  This  philosophy  presumes  a broader  definition  of  event 
than  has  normally  been  used  in  discrete-event  languages: 

An  event  occurs  at  any  point  in  time  beyond  which  the  status 
of  a system  cannot  be  projected  with  certainty. 
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In  GASP  IV  it  is  useful  to  describe  events  in  terms  of  the  mechanisms  by  which  they  are 
scheduled.  Those  that  occur  at  a specified  projected  point  in  time  are  referred  to  as 
time-events.  They  are  commonly  thought  of  in  conjunction  with  “next  event”  simulation. 

Those  that  occur  when  the  system  reaches  a particular  state  are  called  state-events.  Unlike 
time-events,  they  are  not  scheduled  in  the  future,  but  occur  when  state  variables  meet 
prescribed  conditions.  In  GASP  FV,  state-events  can  initiate  time-events  and  time-events  can 
initiate  state-events. 

The  behavior  of  a system  model  is  simulated  by  computing  the  values  of  the  attributes 
at  event  times.  The  time-step  increment  is  automatically  determined  by  GASP  IV,  based  on 
the  equation  form  for  the  state  variables,  the  time  of  the  next  event,  and  accuracy  and 
output  requirements. 

The  key  to  event  simulation  is  the  ability  to  organize  events  so  that  they  are  executed  I 

within  the  computer  in  an  order  corresponding  to  that  which  would  occur  in  the  real 
system.  This  preserves  the  time  relationship  between  simulated  and  real  events.  Ordinary 
programming  languages  are  unsuited  to  this  task  because  they  operate  in  a strictly  sequential 
manner;  there  is  no  way  to  tell  a FORTRAN  program  to  “do  something  later’,  without 
building  special  subprograms.  GASP  IV  provides  these  subprograms. 

Every  GASP  FV  simulation  model  consists  of:  (1)  a set  of  event  programs  or  state  j 

variable  equations,  or  both,  that  describe  a system’s  dynamic  behavior,  (2)  lists  and  matrices 
that  store  information,  (3)  an  executive  routine  that  directs  the  flow  of  information  and 
control  within  the  model,  and  (4)  support  routines.  These  form  an  operating  computer 
program  whose  performance  reflects  that  of  a simulated  system.  A GASP  IV  program  is 
made  up  of  subprograms  linked  together  by  an  executive  routine  that  organizes  and  controls 
the  performance  of  the  subprograms. 

GASP  IV  is  organized  to  provide  eight  specific  functional  capabilities; 

1.  Event  control. 

2.  State-variable  updating  using  integration  if  necessary, 

3.  Information  storage  and  retrieval, 

4.  System  state  initialization, 

5.  System  performance  data  collection, 

6.  Program  monitoring  and  event  reporting, 

7.  Statistical  computations  and  report  generation,  and 

8.  Random  deviate  generation. 
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The  functions  provide  the  user  with  a very  general  tool  with  which  to  build  simulations. 
For  example,  GASP  FV  language  provides  the  basis  for  the  Basic  Simulator  (SIMNUC) 
described  below,  which  in  turn  has  been  used  to  build  the  Distributed  Processor/Memory 
simulation  available  at  AVSAIL. 

1.3.1.3.3  Basic  simulator  (SIMNUC) 

The  Basic  Simulator  (SIMNUC)  is  an  integrated  package  of  subprograms  designed  to 
facilitate  modeling  and  simulation  of  discrete  stochastic  systems  in  a manner  similar  to  the 
GASP  IV  simulation  programs. 

The  following  features  characterize  this  package; 

1.  Model  independence. 

2.  FORTRAN  orientation;  the  user’s  portion  of  a simulator  can  be  programmed  in 
FORTRAN  or,  if  desired,  in  assembly  language. 

3.  Capability  to  produce  event-oriented  simulation  models. 

4.  Availability  of  list  processing  and  dynamic  memory  management  facilities. 

5.  Capability  to  collect  and  display  standard  queue  and  sample  statistics. 

6.  A full  complement  of  random  number  generators. 

The  basic  approach,  which  sometimes  is  referred  to  as  a simulation-world-view,  used  to 
model  discrete  systems  for  digital  simulation  with  the  Basic  Simulator  is  the  event-oriented 
approach,  which  emphasizes  decomposition  of  the  simulation  process  into  individual  event 
procedures,  each  of  which  describes  all  changes  in  the  system  caused  by  the  occurrence  of 
the  related  event,  just  as  was  done  in  GASP  IV . 

The  Basic  Simulator  consists  of  the  following  functional  software  components: 

1.  Dynamic  memory  management, 

2.  List  processing, 

3.  Simulation  run  control, 

4.  Random  number  generators, 

5.  Sample  statistics  processing,  and 

6.  Error  diagnosis  and  reporting. 
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1.3.1. 3.4  Distributed  processor/tnemory  system  network  simulation 


The  advent  of  the  minicomputer  and  the  microprocessor  has  made  available  to  the 
avionics  system  designer  highly  compact  and  versatile  computational  capabilities  that  can  be 
both  physically  and  functionally  distributed  among  avionics  equipments.  Used  in 
conjunction  with  multiplexed  data  buses,  these  processors  make  up  distributed  processing 
systems  presenting  new  challenges  to  the  system  designer. 

The  Distributed  Processor/Memory  (DP/M)  System  Network  Simulator  (SNS)  provides 
the  necessary’  tool  to  explore  some  of  the  tradeoffs  available  to  designers  of  these 
distributed  systems.  The  SNS  is  a discrete,  event-oriented,  high-level  traffic  simulator 
written  in  .‘^NSl  standard  FORTRAN.  The  SNS  is  built  around  a nucleus  of 
model-independent  utility  routines  (SIMNUC)  which  are  not  simulators  in  themselves,  but 
are  used  to  create  a simulator  in  conjunction  with  the  avionic  software  task  specifications 
and  topological  organization  specifications  of  a given  avionics  system. 


The  DP/M  system  concept  is  essentially  the  use  of  varying  numbers  of  simple, 
homogeneous  processor/memory  elements  (PE’s)  applicable  to  a wide  range  of  avionic 
system  processing  problems.  Architecturally,  these  PE’s  can  be  used  as  stand-alone 
uniprocessors,  or  they  can  be  configured  in  a distributed  network  as  shown  in  Figure 
1.3.1. 3-1.  Serial-time-division-multiplex  (TDM)  buses  interconnect  the  network.  Two  levels 
of  busing  are  provided : a Global  bus  can  interconnect  each  PE  in  a system  network,  and  a 
Local  bus  can  interconnect  multiple  PE’s  clustered  together  to  perform  a given  function. 
This  cluster  of  PE’s  is  referred  to  as  an  Affinity  Group  (AG).  Input/ output  (I/O)  for  a given 
PE  to  an  external  device  is  via  its  local  I/O  interface  unit. 


The  SNS,  being  constructed  of  SIMNUC  model-independent  routines,  has  the  same 
general  characteristics  as  SIMNUC  and  GASP  IV.  That  is,  SNS  is  a discrete,  event-oriented 
simulation  system.  Unlike  a continuous  system  where  transitions  from  one  state  to  the  next 
are  a continuous  function  of  time,  transitions  from  one  state  to  another  in  a discrete  system 
occur  at  discrete  points  in  time.  Distinguishable  state  transitions  are  called  events. 
Event-oriented  simulation  systems  emphasize  a detailed  description  of  the  steps  that  occur 
when  an  individual  event  takes  place. 

During  the  period  the  DP/M  SNS  has  been  in  use  at  AFAL,  two  bus  protocol  algorithms 
have  been  implemented.  The  first  is  a modified  “round-robin”  slotting  technique,  which 
provides  for  simple  advancing  of  the  “bus  control  slot”  from  PE  to  PE  in  a predetermined 
order  among  the  total  set  of  PE’s  attached  to  the  bus.  Each  bus  transmission,  referred  to  as  a 
message,  is  terminated  by  the  transmitting  PE. 

The  second  bus  protocol  algorithms  implemented  by  DP/M  SNS  is  that  specified  by 
MIL-STD-1553A  (Aircraft  Internal  Time  Division  Command/ Response  Multiplex  Data  Bus). 
The  basic  difference  between  the  1553 A protocol  and  the  round-robin  protocol  is  that  data 
transfers  occur  only  between  two  PE’s,  one  specifically  designated  as  a transmitter  and  the 
other  as  a receiver.  Three  word  formats  are  defined  for  the  protocol:  (1)  Command  word, 
(2)  Data  word,  and  (3)  Status  word.  One  PE  must  be  designated  as  a bus  controller,  and 
transmissions  are  performed  in  a half-duplex,  synchronous  manner.  Three  message  formats 
are  permitted: 


1.  Controller  to  remote  terminal  (RT)  transfers, 

2.  RT  to  controller  transfers,  and 

3.  RT  to  RT  transfers. 

The  hardware  architecture  represents  one  half  of  the  distributed  avionics  system  design 
problem.  The  other  half  is  the  software,  obviously.  The  DP/M  SNS  assumes  that  the  system 
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desif^ier  will  partition  the  executive  and  applications  software  into  suitable  tasks  for  some 
given  hardware  architecture.  The  SNS  then  provides  the  designer  with  the  capability  to 
analyze  and  evaluate: 

1.  Processing  element  characteristics/capabilities, 

2.  Number  of  resources  in  the  system, 

3.  Local  and  global  bus  configuration, 

i -1.  Inter-PE  communication  technique, 

5.  PE  Bus  protocol  communication  technique,  and 
! 6.  Executive  control  technique. 

The  SNS  is  predicated  on  the  representation  of  software  modules  by  a directed  graph 

consisting  of  a set  of  nodes  and  a set  of  directed  edges  between  these  nodes.  A node  is  used 

} 

to  represent  a set  of  computations  which,  once  initiated,  can  run  to  completion  without 
waiting  for  completion  of  another  set  of  computations  also  represented  by  a node.  An  edge 
from  node  i to  node  j means  that,  upon  completion  of  the  computations  represented  by 
node  i,  the  computations  by  node  j can  be  initiated. 

The  representation  of  software  execution  sequences  via  a directed  graph  has  a particular 
advantage  within  the  DP/M  concept.  The  subfunction-directed  graph  reveals  potential 
process  construction  options  in  allocating  tasks  and  program  to  PE’s.  If  any  one  set  of  tasks 
must  be  partitioned  among  several  PE’s,  the  options  available  in  allocating  this  software  to 
PE’s  are  clearly  defined  within  the  graph.  Data  sets  that  are  passed  from  one  task  to  another 
represent  Local  bus  messages  if  their  respective  tasks  are  not  collocated  in  the  same  PE. 
Likewise,  collocated  tasks  need  not  generate  bus  traffic  with  their  data  interchanges. 

The  use  of  distributed  PE’s  in  the  DP/M  system  concept  dictates  the  need  for  a method 
of  scheduling  activities,  transferring  bus  messages  between  PE’s  and  general  system  control. 
These  operations  are  referred  to  as  Executive  functions  and  are  provided  by  the  SNS.  The 
subfunction-directed  graph  contains  the  necessary  information  from  which  the  Executive 
■ can  determine  task-scheduling  conditions  (based  upon  required  predecessor  events)  and 

intertask  communication.  The  DP/M  Executive  structure  provides  two  levels  of  control:  the 
Global  Executive  (GEX)  and  the  Local  Executive  (LEX).  Functionally,  the  GEX  assumes 
the  role  of  system  monitor  and  scheduler.  It  enforces  subfunction  interrelationships  and  is 
respon.sihle  for  system  performance  by  coordinating  those  software  programs  required  to 
effect  mission  avionic  functions  for  the  pilot  and  aircraft.  The  LEX  is  a PE-oriented 
function  responsible  for  sequencing  and  controlling  tasks  assigned  to  a PE.  The  LEX  is 
concerned  with  scheduling  those  tasks  assigned  to  its  PE,  based  upon  successful  satisfaction 
‘ of  all  the  tasks’  given  predecessor  conditions. 

i 
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The  Global  Executive  schedules  time-dependent  subfunctions  in  the  DP/M  system.  A 
time-ordered  linked  list  provides  the  GEX  with  the  relative  times  to  schedule  every 
time-dependent  subfunction  in  the  system.  A “go”  message  is  generated  by  the  GEX  to  a 
subfunction  only  if  other  predecessor  conditions  for  the  subfunction  have  been  satisfied 
when  it  is  time  to  run  the  subfunction.  The  GEX  data  base  (or  tables)  contains  all 
information  pertaining  to  the  initialization  and  control  of  all  time-dependent  subfunctions 
in  the  DP/M  system. 

A family  of  data  collection  and  report  generation  programs  is  provided  with  the  DP/M 
System  Network  Simulator.  These  programs  provide  the  capability  to  selectively  collect  data 
on  and  generate  reports  for  the  various  system  parameters  under  investigation  for  a 
particular  DP/M  system  configuration  and/or  avionic  mission  segment.  The  collection  and 
dispensation  of  data,  as  well  as  generation  of  reports,  are  controlled  by  user  specified 
parameters.  In  general,  the  user  has  four  options;  (1)  no  data  is  collected  and  no  reports 
generated;  (2)  data  is  collected  and  saved,  but  no  report  generated ; (3)  data  is  collected  and 
report  generated,  but  data  not  saved;  or  (4)  data  is  collected  and  saved,  and  reports  gener- 
ated. Data  saved  on  tape  may  be  processed  at  a later  time.  In  fact,  this  saved  data  may  Ix' 
used  at  a later  time  to  compare  results  of  two  or  more  different  simulation  experiments. 

Data  collection  and  report  generation  occur  at  three  distinct  levels;  (1)  event  level,  (2) 
sample  period  level,  (3)  postsimulation  level.  At  each  of  these  levels,  reports  concerning  bus 
performance,  processor  loading,  exe<’utive  performance,  and  number  of  avionic  (.asks 
processed  may  be  selectively  generated. 

1.3. 1.3.5  Software  design  and  verification  system  (SDVS) 

Software  tools  to  aid  in  the  development,  testing,  verification,  and  maintenance  of 
avionic  mission  software  are  provided  by  SDVS.  Simulations  available  under  SDVS  are 
non-real-time.  The  SDVS  was  created  as  an  integral  part  of  the  DAIS  program,  and  the  user 
will  encounter  some  constraints  imposed  by  the  DAIS  concept.  Since  the  use  of  common 
hardware  and  software  for  acquisition  of  sensor  data,  processing  of  information,  and 
provision  of  display  information  is  key  to  the  DAIS  concept,  the  software  design  and 
verification  functions,  in  the  context  of  any  particular  processor  architecture,  are  vital  to 
success.  These  same  considerations  for  software  integrity  are  common  in  some  degree  to  all 
avionic  software  developments.  Thus,  SDVS  can  play  an  important  role  in  software 
development. 

The  basic  functions  provided  by  SDVS  are  depicted  by  Figure  1.3. 1.3-2.  Configuration 
Management  refers  to  provisions  for  control  of  all  files  associated  with  the  development. 
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Figure  1.3.1. 3-2.  SDVS  functional  organization. 


test,  and  verification  of  software.  .\n  extensive  cataloging  and  security  system  is  provided 
for  the  various  types  of  software  mainUtined  by  SDVS.  .•\  set  of  interactive  conversational 
commands  is  provided  by  the  File  Management  function;  these  commands  enable  the  user  to 
perform  various  file  manipulation  activities  necessriry  during  softwam  development.  In 
interpreting  these  commands,  the  Configuration  Management  catalogs  are  interrogated  to 
determine  if  the  user  has  file-access  authority  and,  if  .so,  the  type  of  access  authority. 

.Software  Development  Management  functions  are  divided  into  two  groups.  In  order  to 
test  software  efficiently  and  comprehensively,  an  easy-to-use  man/machine  interface  is 
necessar,’  to  facilitate  the  specification  of  the  simulated  environment,  data  to  lie  recorded, 
and  the  required  processing  of  simulation  data.  Two  special  purpose  languages,  the 
Simulation  Control  Language  and  the  Data  Processing  Language  are  provided  by  SDVS  for 
these  purposes.  Testing  and  validation  of  software  are  facilitated  by  several  tools  provided 
by  SDVS,  the  first  being  the  support  facility  function,  which  is  D.AIS-specific  and  not 
directly  applicable  to  other  software  development  programs.  .A  second  testing  and  validation 
software  function  is  provided  by  four  simulators.  These  simulators  model  proce.ssor  and  bus 
performance  in  the  execution  of  mission  software; 

1.  Statement  Level  Simulator, 

2.  Interpretive  Computer  Simulator, 

3.  Data  Bus  Simulator,  and 

4.  External  Environment  Simulator. 
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The  External  Environment  Simulator  is  quite  general  and  applicable  to  any  avionic 
software  development.  The  other  three  would  have  applicability,  depending  on  the 
similarity  of  a given  software  program  to  that  of  the  DAIS  program  since  they  simulate 
DAIS  hardware.  They  are  of  interest,  of  course,  from  the  standpoint  of  the  testing  and 
validation  concepts  they  illustrate  and  their  potential  adaptability  to  other  programs. 

The  function  provided  by  Postrun  Processing  is  that  of  sorting,  editing,  analyzing,  and 
outputting  simulation  data  from  the  various  software  simulations.  The  Rough  Output  Tape 
generated  during  a simulation  run  is  processed  and  output  to  the  user  by  this  function. 

1.3.1.3.6  Avionics  simulation  (AVSIM) 

AVSIM  is  a simulation  facility  that  affects  avionics  system  evaluation,  validation,  and 
integration  by  dynamic  digital  simulation  of  the  airframe,  flight  controls,  and  avionic 
equipments  of  a generic  high-performance  tactical  fighter.  Currently,  the  objectives  of  this 
facility  are: 

1.  To  test  and  validate  operational  flight  programs  under  realistic  flight  conditions, 

2.  To  affect  digital  avionics  system  integration, 

3.  To  identify  hardware/software  problems  in  prototype  avionics  systems,  and 

4.  To  recreate  flight  problem  areas  through  dynamic  simulation. 

AVSIM  is  capable  of  simulating  the  navigation,  penetration,  and  weapon-delivery  phases 
of  an  attack  fighter  mission,  either  individually  or  compositely.  The  AVSIM  user  configures 
his  aircraft,  sensor  complement,  environmental  characteristics,  and  target  characteristics  by 
linking  individual  simulation  models  into  an  overall  simulator  structure.  The  AVSIM 
simulator  currently  has  real-time,  non-real-time,  man-in-the-loop,  and  self-contained  modes 
of  operation.  The  user  has  the  option  to  use  resident  (F-16)  software  developed  by  General 
Dynamics,  Ft.  Worth;  to  use  resident  (A7)  software  obtained  from  the  Navy;  or  to  develop 
his  own  by  utilization  of  resident  creation  routines. 

In  the  example  of  the  resident  software,  the  airframe  is  configured  by  selecting  either  an 
F-16  or  an  A7  aircraft  model;  an  appropriate  flight  control  system  dependent  on  desired 
complexity;  and  self-contained  (synthetic  mission  generator/ simulated  pilot),  prerecorded, 
or  real-time  cockpit  inputs.  The  sensor  complement  presently  available  includes  the  radar 
altimeter,  the  attack  radar,  and  (may  be  extended  to  include)  electro-optical  sensors.  Flight 
environment  is  incorporated  by  using  models  that  provide  simulated  air  data  inputs, 
accelerometer  and  gyro  outputs,  representative  weather  effects,  atmospheric  perturbations. 
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morlud  outputs,  ami  inumu'lu'  hoatlinn.  Auxiliary  software  iuU'ural  to  tlu>  total  simulation 
im'liulos  an  iuortial  roforonoi',  noomotry  oflVrts,  and  (ho  ability  to  introduoo  noiso  at  various 
points. 

AVSIM  is  hostod  by  tbo  I)K(MO  facility  at  AFAl.  and  is  linked  to  porit)borals  such  as 
the  cockpit  and  display  uonorator  by  moans  of  a DMA  channol  to  satollito  1M)P-1 1's,  AVSIM 
software  consists  of  control  modules  and  application  models,  'riie  control  .software  provides 
tile  mam|)ulation,  sets  up  the  simulation  confifruralion.  firovides  initiali/ation,  implenuaits 
inan/macbme  interface,  and  controls  overall  the  execution  senuence.  'I'lie  application  models 
provide  aforementioned  sensor  data,  external  physical  conditions,  etc.  Also  containiHl  with- 
in the  software  are  data  acquisition  and  analysis  modules,  which  accumulate  and  edit  data 
for  validation  :in:ilysis. 

AVSIM  programs  are  coded  largely  in  ANSl-FOUI'K AN  in  an  attempt  to  make  the 
software  flexible,  modular,  and  transferable.  1)F,('  system  FtlK  l'KAN-lO  features  as  well  as 
1)F,('-10  a.ssembly  lanitua^e  are  also  used  to  a lesser  detjree. 

1.3. 1.3. 7 Processor  architecture  (ISP) 

The  ISP  processor  simulation  facility  enables  a user  to  describe  cominiter  processing 
units  at  (he  register  trjinsfi’r  l<'v<>l  and,  from  the.si’ de.scriptioiis,  to  quickly  set  up  interactive 
simulations  of  these  processors.  A lan»{uat?e.  C’SI,/1S1’  (tUmiputer  Simulation  lannuatte)  was 
devehqied  as  a dialect  of  Instruction  Set  Processor  language  (ISPLI  from  ('jirnegie-Mellon 
University.  A compiler  produces  1)F,(M0  code  from  the  CSL/ISP  source,  and  the  user  then 
runs  this  code  from  a control  pro({ram,  which  he  constructs  by  modifying  a model  Keneral 
purpose  simulation  control  proKram.  A methodolojjy  is  included  for  cii'atinn  simulations 
from  manufacturers’  instruction  set  descriptions. 

Phe  processor  simulation  proKnim  can,  from  a descri|itioii  of  the  retfisti'r  transfers  of  a 
cominiter,  pnniuce  a simulation  of  that  computer.  Phis  pronram  may  be  broken  into  three 
general  areas.  ’Phese  include;  a formal  lanituaite  compiler  with  which  to  describe  register 
transfer  level  processes,  a code  generator  to  produce  l)F.('-U)  cinle  from  the  output  of  a 
compiler  for  that  language,  and  a general  purpose  control  program  with  which  to  drive  the 
simulators  produced  from  the  I’onipiler. 

Phe  compili'r  uses  a set  of  register  transfer  operators,  called  X'P-op’s,  to  produce  a set  of 
pseudo  instructions,  which  can  b(>  interpreted  by  the  nF-(’-lO  assembler's  tMAt'Kt"))  macro 
facility.  'Phe  macros,  which  were  written  to  produci’  I)F('-1()  code  from  the.sc 
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pseiiilo-instnu'tums,  pri»<liif«'  oplimi/.t'd  oiulo  aiul  i'onipns«>  a univorsal  library,  wliirh  is 
soarohiMl  diinuK  ass*>ml>ly 

Sumilations  an'  contrnUt'tl  l<y  a program  with  whicli  tlio  visor  oaii  intoraolivoly  sol 
r»'nistors  aiul  momory  liH’almiis,  load  luoniory.  sot  lm*akpoints.  oti'.  I'lio  oontrol  pro){rani 
(■avisos  iiistriioluins  m sinnilatod  nioiiior>'  to  Im'  oxi'ovilod  by  n'potitivoly  oalliiiK  on  Iho 
snmilator  tv)  oxv'onlo  a sinKb'  insiriivlion. 

Tbo  bobavuvr  of  a pn)ov'ssor  is  ilolonniiu'il  by  tbi'  ivaUiro  of  its  iiulivuUial  oporations  and 
tho  soijuono)'  in  wliioh  tbosv’  oporations  ooonr.  This  sv'pvioiu'v'  is  tjv'noraUy  novorni'vl  by  a 
storvxl  program,  whiob  rosulos  in  tbo  inoinorx'  v)f  tbo  oonipntor  anil  Ibv' si't  of  intor|)rolation 
nilos  whiob  Iho  prooi'ssor  aivi'lu's  to  Iho  program. 

Althonish  Iho  abovo  format  is  ooininonly  nsv»d  li)  di'si’nbt'  ditiilal  oompiiti’vs,  ISl’  dot's 
not  limit  Ihi'  iisi'r  to  a parlionlar  lypi'  I'f  vh'soriplion.  Thus.  ISl’  van  bo  list'd  to  di'st'ribo 
rt'vjistt'r  transfor  systoms  in  nt'nt'ral;  ili);ital  oomi'iitt'rs  art'  a snbst'l  of  snob  sysli'ms  whioh 
inlorprot  an  instriiolion  st't.  Vithor  ilovioos,  siu'li  as  bnsi'N  aiul  dovu't'  t'onirolli'rs  t'an  also  bt' 
tlt'soriboil  in  ISP. 


1.3.1.3.8  Communication  system  evaluation  laboratory  (CSEL) 

('SKL  is  a I'ombinod  hanlwaro/softwaro  faoility  tlosiunoil  to  analyzo.  synthosi'/.o.  ami 
modol  advanotnl  oomnumioation  systoms.  Tbo  laboratory  oontors  about  a oompiitor  basixl 
simulation  facility,  which  is  capablo  of  croating  a variety  of  hostilo  UK  siKiial  onviromni'iits 
at  UHF  and  li-.  X-,  and  K-band.  To  this  facility  may  lu'  intorfacod,  for  toslinjj  and 
^•vnluntion.  oithor  laboratory -motlol  communication  hardware,  actual  communication 
himlwaro.  or  a combination  of  olomonts  of  Inrth.  To  aitl  in  tho  construction  of  laboratory 
t'omnuinications  systoms,  CSKl,  provitlos  a hijjh-spood.  pronrammablo  siKnal  procossor  anti  a 
spoi'tnim  of  communication  equipment . includinn  moiloms,  terminals,  and  antenna  systems. 

It  is  important  to  note  that  the  simulation  facility  just  mentioniHl.  calltHl  the  Signal  and 
Interference  Generator,  produces  simulatiHl  sinnal  environments  in  the  appropriate  UK  baiitl. 
'ITiii.s.  it  qualifies  ns  a harvlwnre  simulator,  control  over  which  is  v'xv'rt'istHf  dynamically  by  a 
digital  computer  operating  in  n'lil  time.  Initial  confitiurinu  of  the  simulator  is  also  performed 
through  the  diKitnl  controller  by  means  of  a series  of  user  commands,  which  the  system 
software  interprets  and  translatv's  into  control  sinnnls  to  the  communication  hartlwart'. 

InlorfaciuK  communication  terminals  tt)  the  Siitual  aiul  Interfort'ivce  Generator  UK 
hardware  then  provides  a roalistio  lost  boil  for  tho  terminals,  in  which  one  can  not  only 


t roubloshoDt  tlio  I'quipint'nt  but  also  tost  its  pt'rformanoo  witli  rosp»>ct  to  siu'h 
onvironmoiital  effoots  as  jamming  and  fadint;.  ’I’lio  user  i-an  spooify  tlu-so  offocts  with  rolativo 
oast'  and  tan  vary  thorn  rt'atlily  frt)m  t>no  tost  run  to  tlio  noxt,  thoroby  oblainin>;  a ooinploto 
oharaotorizatittn  t)f  tl\o  porformanoo  oapabilitios  t)f  his  otiuipmont. 

A typical  application  of  C'SKL  is  illustrated  by  tho  tests  porformod  to  dotorinino  the 
suitability  of  the  LKS-8/9  coinnuinicatitin  satellites  for  use  with  tho  Airborne  t'oinmand 
Post.  In  those  tests,  CSKL  was  usetl  not  only  tt)  trtiubleshoot  Ka-band  ctimmunication 
hardware,  but  also  to  ascertain  the  vulnerability  of  the  cominuniiation  system  to  various 
types  of  jamming. 

To  accomplish  these  uoals,  ('SKI,  was  equippeil  with  appropriate  K-band  and  UHK 
communication  modems,  terminals,  and  antennas.  This  confi(turation  allowed  use  of  the 
communication  satelliti'  in  a laboratory  system  equippeil  with  a (lualifii-ation  model  of  the 
.■\N/AS('  Ka-band  airborne  communication  terminal,  together  with  antenna  systems,  to 
establish  communication  links  with  I,KS-S/9.  This  equipment,  when  combined  with  the 
Siinial  and  Interference  (lenerator,  allowed  the  realization  of  actual  satellite  communication 
channels  ii  which  were  introduced  controlled-interference  efforts  in  the  form  of  jamming;, 
fadinn,  and  iloppler.  To  reinforce  this  capability,  the  hinh-speed  signal  processor,  called  the 
Programmable  Data  I'erminal.  was  proitrammed  to  simulate  satellite  processing  when 
I,KS-8/t)  were  unavailable  to  use. 

Current  emphasis  in  CSKl,  is  shifting  towaril  a study  of  the  performance  of 
communication  systems  linking  remotely  piloted  vehicles  with  air-  and  ground-based 
command  posts.  To  this  end,  the  facility  is  being  upgraded  to  include  the  elements  of  a 
video  proce.ssing  and  liisplay  capability.  Future  studies  envisioned  for  CSKL  involve  .satel- 
lite-based navigation  systems  and  the  performance  they  obtain  in  a hostile  environment. 

1.3.2.  Electronic  Technology  Division 

To  be  included  in  a future  version  of  tins  manual. 

1.3.3  Electronic  Warfare  Division 

To  be  included  in  a future  version  of  this  manual. 

1.3.4  Reconnaissance  and  Weapon  Delivery  Division 


To  be  incluih'd  in  a future  version  of  this  manual. 
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SECTION  II 

AVIONIC  SYSTEM  ANALYSIS  AND  INTEGRATION  LABORATORY  (AVSAIL) 

Z^  AVSAIL  HOST  FACILITY 

The  AVSAIL  host  facility  has  been  configured  particularly  for  implementation  of  all  the 
simulation  classes  previously  described.  In  order  to  convey  the  flexibility  and  power  of  the 
AVSAIL  laboratory,  the  host  facility  is  described  in  the  foliowring  sections.  The  scope  of  the 
descriptions  is  limited  to  those  aspects  of  the  facility  which  have  significance  to  the  conduct 
of  simulations,  rather  than  to  an  exhaustive  exploration  of  capability.  Discussions  are 
provided  of  the  basic  computer  and  peripheral  hardware  configuration  and  performance,  the 
operating  and  utility  software  capabilities,  and  the  communication  interfaces  to  onsite 
simulators  and  offsite  users. 

The  concept  of  AVSAIL  encompasses  all  of  the  analysis  and  integration  functions 
necessary  to  create  innovative  avionics  systems.  These  functions  are  best  illustrated  by  the 
discussion  of  the  simulation  class  structure  in  Section  1.2  of  this  manual.  One  of  the  more 
important  aspects  of  the  AVSAIL  concept  is  the  need  for  a simple  interactive  interface  for 
the  user  of  the  laboratory  host  facility.  The  complex  nature  of  the  problems  which  may  be 
investigated  in  this  laboratory  imply  many  users  over  extended  periods  of  time.  The  systems 
being  designed  will  be  subjected  to  evolutionary  modifications,  necessitating  comparisons  of 
performance  of  components  and  systems  at  various  stages  of  the  design.  In  order  for  the 
AVSAIL  facility  to  provide  the  degree  of  interaction  and  flexibility  required  to  simulate  a 
wide  range  of  systems  and  operational  scenarios,  the  facility  architecture  of  Figure  2.1-1  was 
proposed. 

This  architecture  demonstrates  the  explicit  requirement  that  the  user  be  allowed  to 
address  the  simulation  facility  without  regard  to  facility  management  and  control 
constraints.  This  is  achieved  by  use  of  appropriate  interface  structure,  which  translates  user 
requirements  into  facility  inputs  interactively.  The  focal  point  of  the  simulation  facility 
architecture  is  the  simulation  control  program,  which  addresses  the  various  simulation  levels 
and  handles  the  control  and  response  files  according  to  user  requirements. 

A set  of  simulation  models  is  available  to  the  user  in  the  model  data  base.  Models 
currently  available  are  described  in  this  manual  and  others  may  be  added  as  required.  The 
user  may  modify  model  parameter  values  for  his  particular  simulation  needs,  modify 
models,  or  create  his  own  models  and  add  them  to  the  data  base.  Such  modifications  or 
additions  to  the  data  base  would  be  under  the  supervision  of  the  facility  manager,  however. 


LEVEL  I 
SIMULATION 


Fi|M«  2.1-1.  AVSAIL 


In  order  to  simulate  a system  or  component,  the  user  would  create  a simulation  control 
file  that  would  specify  such  items  as  flight  scenarios,  system  configuration,  model  selection, 
model  parameters,  simulation  time  frames,  data  recording,  data  analysis,  and  component 
performance  or  reliability.  The  simulation  control  program  then  accesses  the  model  data 
Iwse,  configures  the  simulation,  runs  the  simulation,  and  records  the  outputs  as  defined  hy 
the  control  file.  At  the  completion  of  the  run,  the  simulation  response  file  contains  a recortl 
of  system  performance  paramett'rs  defined  by  the  user  in  a format  compatible  with  all 
models  in  the  model  data  base  and  with  outputs  of  other  simulation  levels  so  that  the  results 
of  other  past  or  future  simulations  may  be  compared  with  current  results.  This  allows 
parametric  studies  or  evolutionary  designs  to  be  carried  out  through  the  mechanism  of 
simulation. 

The  simulation  control  program  is  responsible  for  control  of  computer  facility  liardwaie 
and  software  resources  for  both  real-time  and  batch  simulations.  The  user  is  not  required  to 
directly  interface  with  the  management  functions  of  an  executing  simulation  or  the  data 
generated  by  the  simulation.  This  allows  the  facility  management  to  control  the  software 
implemented  on  the  facility  so  as  to  ensure  compatibility  of  all  levels  of  simulation.  The 
user  interactive  interface,  on  the  oUrer  hand,  provides  a flexible  means  for  structuring 
simulations  of  a wide  range  of  avionic  systems  and  analyzing  their  results  in  a manner  best 
suited  to  the  purposes  of  the  individual  users. 

While  the  concept  of  AVSAIL  just  described  has  not  lieen  fully  implemented  for  the 
overall  system  as  described  by  Figure  2.1-1,  it  has  been  implemented  within  some  of  the 
major  software  packages,  such  as  the  Software  Design  and  Verification  System  (SDV'Sl  and 
the  AVSIM  avionic  simulation  package. 

2.1.1  Hardware 

As  can  be  seen  from  subsequent  discussions  of  specific  simulator  and  .soft  ware  programs, 
significant  simulation  capability  already  exists,  whose  use  requires  little,  if  any,  knowledge 
of  the  AVSAIL  laboratory  hardware  cajxibility.  However,  the  planning  and  integration  of 
new  simulators  or  the  execution  of  major  software  simulations  must  lie  done  with  the  host 
facility  constraints  in  mind. 

2.1. 1.1  DECsystem- 10  Core  Facility 

2.1 .1 .1 .1  System  description 

The  AVSAIL  laboratory  is  structured  around  a Digital  F.quipment  Cor^ioration  DEC-10 
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mainframe  computer.  A wide  range  of  peripheral  input/output  devices,  as  described 
subsequently,  are  provided  to  handle  batch,  timeshare,  and  real-time  program  development 
and  execution  requirements.  A unique  feature  of  the  AVSAIL  configuration  is  the 
eight-channel  Direct  Memory  Access  (DMA)  capability  provided  for  access  by  a complement 
of  eight  PDP-11  series  minicomputers.  The  PDP-11 ’s  serve  to  interface  specific  simulations 
(e.g.,  the  F-16  Fire  Control  Computer  simulator)  to  the  DEC-10.  An  overall  hardware 
system  diagram  is  provided  in  Figure  1.3. 1.1-1,  and  the  major  elements  are  briefly  described 
below. 


2.1. 1.1. 1.1  DEC-10  Central  Processor  and  Main  Memory.  The  central  processing  unit 
(CPU)  for  the  AVSAIL  DEC-10  consists  of  dual  Kl-10  processors,  with  the  configuration 
l)eing  designated  as  a DEC-1077.  Each  CPU  module  is  an  independent  processor,  and 
programs  can  operate  in  parallel,  one  program  per  processor,  thereby  increasing  the  average 
throughput  speed.  Other  performance  characteristics  of  the  DEC-1077  are  given  in  Table 
2.1.1. 1-1. 

.As  shown  in  Figure  1.3. 1.1-1,  the  DEC-10  memory  is  made  up  of  4 DEC  64K  modules, 
and  an  additional  512K  words  of  Ampex  ARM-IOLX  memory,  for  a total  of  768K  words. 
Word  size  is  36  bits  plus  parity.  Each  of  the  memory  modules,  as  well  as  the  CPUs  and  data 
channels,  are  interfaced  via  the  memory  bus.  The  structure  of  the  memory  bus  gives  the 
central  processor  and  high-speed  data  channels  simultaneous  access  to  separate  memory 
modules  and  allows  each  to  operate  at  its  own  speed.  The  memory  bus  system  allows  each 
daUi  channel  to  transmit  full  36-bit  words  in  parallel  at  a speed  of  1 million  words  per 
second.  In  total,  the  memory  structure  operates  at  rates  of  up  to  10  million  characters  per 
second  when  I/O  devices  and  processors  are  simultaneously  transferring  data. 


TABLE  2.I.I.M.  DEC-1077  PERFORMANCE 


Memory  size  (min  • max) 

1284096K 

Instruction  times  (^s) 

No.  of  instructions 

378 

Fixed  point  add 

1.5 

Instruction  look-ahead 

Yes 

Fixed  point  multiply 

4.1 

Virtual  mamorv 

Yes 

Jump 

1.1 

Memory  interleaving 

2 or  4 way 

Single  precision  floating  point  added 

3.6 

Index  registers 

4X1S/CPU 

Double  precision  floating  point  added 

7.6 

Accumulators 

4X  15/CPU 

I/O  bus  band  width,  words/$ 

370K 

Memory  bus  bandwidth  words/s 

4000K 

2.1. 1.1. 1.2  Bulk  Storage.  Bulk  storaf^e  is  available  botli  on  multisurfaee  eartridjte  disks 
and  magnetic  tape.  All  disk  and  tape  units  art'  interfaced  to  both  the  I/O  bus  and  to  the 
memory  bus. 


The  system  currently  provides  four  RP03  disk  drives  and  four  RP04  disk  drives.  The 
RP03’s  and  RP04’s  are  separately  interfaced  as  shown  by  Figvire  3. 1.1. 1-1.  Some 
performance  characteristics  of  these  disk  drives  are  given  in  Table  2.1. 1.1-2.  Storage 
capacity  of  the  RP04’s  is  twice  that  of  the  RP03’s.  and  transfer  rate  is  nearly  triple  Urat  of 
the  RP03’s. 


Magnetic  tape  drives  available  also  provide  a choice  of  performance.  Four  TUIOA-K 
9-track  drives  operate  at  45  ips  and  four  TU  40  drives  operate  at  150  ips,  providing  a range 
of  transfer  rates  from  9K  to  120K  characters  per  second.  Additional  performance  data  is 
given  by  Table  2. 1.1. 1-3. 

2.1. 1.1. 1.3  User  Interface.  The  DEC-10  facility  provides  for  onsite  and  offsite  accesis  for 
both  development  of  software  and  for  its  execution.  Currently,  onsite  facilities  include  25 
CRT  alphanumeric  terminals,  2 local  CRT  graphic  display  terminals  and  2 minicomputer 
lutstal  data  acquisition  systems.  In  addition  to  these  physical  terminals,  the  DEC- 10  monitor 


TABLE  2.1.1.1-2.  DISK  DRIVE  SYSTEM  CHARACTERISTICS 


Chiractcristic 


RP03  Disk 


RP04  Disk 


Disk  drivt  cipMitv 
Transfer  rata 
Accass  tima; 
Trackto-irKk 
Avaragt 
Maximum 
Organiiation: 


Numbar  of  haads 
Numbar  of  rKording  surfacas 
Numbar  of  disks 
Numbar  of  drivas/controllar 
Numbar  of  drivas/systam 
Maximum  storaga/systam 


10.24  million  words 
ISfis/word 

7.5  ms 
29  ms 
55  ms 

128  words/sactor 
10  sactors/trKk 
20  trKks/cylindar 
400  cylindars/pKk 
20 
20 
11 
8 
32 

1.96  billion  charKtan 


20.48  million  words 
5.6  |js/word 

7 ms 
28  ms 
50  ms 

128  words/sactor 
20  SKtors/track 
19  tracks/cylinder 
4 1 1 cylindars/pack 
19 
19 
12 
8 
32 

3.92  billion  characters 
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TABLE  M.1.1-3.  MAGNETIC  TAPE  DRIVE  CHARACTERISTICS 


ChtrKttrittic 

TU10AE 

TU40 

Tap*  tpttd 

45  ipt 

150  ipt 

Tnnsftr  iat«  at; 

220  bpi 

9K  char/i 

30K  char/i 

S56  bpi 

25K  char/s 

83.4K  char/t 

800  bpi 

36K  uhar/i 

120K  char/t 

Racording  tKhnique 

NRZI 

NRZI 

Nomial  intarracord 

Gap: 

9 trKk 

0.6  in. 

0.6  in. 

Rawind  time  (2400  ft) 

195 1 

66 1 

software  support  up  to  48  virtual  terminals  or  “pseudo-toletypes”  which  allow  jobs  to 
control  other  jobs.  Normally  a job  is  associated  with  a physical  terminal,  but  the 
pseudo-teletype  function  allows  jobs  to  be  initiated  and  controlled  by  other  jobs.  A 
controlling  job  sends  the  sjime  kinds  of  commands  to  its  subjobs  as  would  be  sent  by  a user 
at  a physical  terminal,  and  the  monitor  does  not  distinguish  jobs  controlled  by  a physical 
terminal  from  those  controllt>d  by  a pseudo-teletype.  The  physical  user  interface  is  thus 
e.xpanded  by  software  to  increase  system  throughput  potential.  The  physical  terminals  just 
describeil  are  interfaced  to  the  DEC-10  through  DC76-DA  Data  Communications  System 
(Figure  1.3. 1.1-1).  .-\synchronous  lines  operating  at  300  baud  connect  to  the  terminals, 
although  interface  capability  is  for  9,600  baud  maximum  line,  and  a maximum  aggregate 
transfer  rate  of  30,000  bps. 

Off-site  access  to  the  DEC-10  is  through  the  DC7  j Data  Communications  System 
(Figure  1.3.1. 1-1)  which  provides  a maximum  of  eight  synchronous,  9,600  baud  lines. 
Maximum  aggregate  data  rate  is  30,000  bps.  Currently,  4,800  baud  full-duplex  leased  lines 
connect  the  AVSAIL  laboratory  through  this  interface  with  the  Armament  Development 
Center,  Eglin  AFB,  Florida,  and  the  Naval  Weapons  Center,  China  Lake,  California. 

2.1. 1.1. 1.4  Hard  Copy  Devices.  Two  line  printers  provide  high  speed  output  from  the 
DEC-10.  The  1,250  line  per  minute  LPIOF.V  is  a 132  column  format  printer  with  a 64 
character  EDP  font.  The  LPIOHC  provides  the  sjime  performance,  but  has  a 96  character 
scientific  font,  tlruphical  hard  copy  output  is  available  from  a Calcomp  Minlel  563  Plotter. 
This  high  speed,  drum-type  pen  and  ink  plotter  uses  31  in.  paper  and  operates  at  up  to  300 
steps  per  second.  Can!  input  to  the  system  is  available  through  a CRIOE  1,200  card  per 
minute  rentier. 
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2.1. 1.1. 2 DECsystem-10  processor  features 


In  order  to  convey  some  of  the  power  of  the  DEC-10,  some  of  the  more  important 
features  are  described  in  the  following  paragraphs.  These  features  will  be  of  more  value  to 
the  user  initiating  a major  new  simulation  than  to  those  using  or  modifying  slightly  existing 
simulations. 


2.1. 1.1. 2.1  Instruction  Set.  The  KIIO  has  378  instructions,  an  extremely  large 
repertoire  which  provides  the  flexibility  required  for  specialized  computing  problems.  Since 
the  set  provides  so  many  instructions  to  choose  from,  few  instructions  are  required  to 
perform  a given  function.  Assembly  language  programs  are  therefore  shorter  than  with  other 
computers,  and  the  instruction  set  simplifies  the  Monitor,  language  processors,  and  utility 
programs.  For  example,  compiled  programs  on  a DEC-10  are  often  30  to  50  percent  shorter, 
require  less  memory  and  execute  faster  than  those  of  comparable  computers. 

In  addition  to  these  instructions,  the  DEC-10  provides  64  programmable  operators,  33 
of  which  “trap”  to  the  Monitor  (Monitor  calls)  and  31  of  which  trap  to  the  user’s  core  area. 
The  remaining  instructions  are  unimplemented  and  reserved  for  future  expansion.  An 
attempt  to  execute  one  of  these  unimplemented  instructions  results  in  a trap  to  the 
Monitor. 


The  instruction  set,  despite  its  size,  is  easy  to  learn.  It  is  logically  grouped  into  families 
of  instructions  and  the  mnemonic  code  is  constructed  modularly.  All  instructions  are 
capable  of  directly  addressing  a full  256K  (36-bit)  words  of  memory  without  resorting  to 
base  registers,  displacement  addressing,  or  indirect  addressing.  Instructions  may,  however, 
use  indirect  addressing  with  indexing  to  any  level.  Most  instruction  classes,  including 
floating-point,  allow  immediate  mode  addressing,  where  the  result  of  the  effective  address 
calculation  is  used  directly  as  an  operand  in  order  to  save  storage  and  speed  execution. 

The  half-word  data  transmission  instructions  move  a half-word  and  may  modify  the 
contents  of  the  other  half  of  the  destination  location. 

The  full-word  data  transmission  instructions  move  one  or  more  full  words  of  data  from 
one  place  to  another.  The  instructions  may  perform  minor  arithmetic  operations  such  as 
forming  the  negative  or  the  magnitude  of  the  word  being  processed.  The  five  byte 
manipulation  instructions  pack  or  unpack  bytes  of  any  length,  anywhere  within  a word.  The 
logic  instructions  provide  the  capabilities  of  shifting  and  rotating,  as  well  as  performing  the 
complete  set  of  16  Boolean  functions  on  two  variables. 
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The  KIIO  processor  implements  instructions  to  perform  scaling,  negating,  addition, 
subtraction,  multiplication,  and  division  upon  numbers  in  single-precision  and 
double-precision  floating-point  format.  In  the  single-precision  floating-point  format,  1 bit  is 
reserved  for  the  sign,  8 bits  are  used  for  the  exponent,  and  62  bits  are  used  for  the  fraction. 

' Special  KUO  instructions  provide  the  capability  of  converting  fixed-point  formats  to  or 

from  floating-point  formats.  Two  sets  of  instructions  are  provided  to  perform  this  function: 
one  set  optimized  for  FORTRAN  and  a second  set  optimized  for  ALGOL. 

The  arithmetic  testing  instructions  may  jump  or  skip,  depending  on  the  result  of  an 
arithmetic  test  and  may  first  perform  an  arithmetic  operation  on  the  test  word.  Instructions 
are  also  provided  to  modify  and/or  test  using  a mask  and/or  skip  on  selected  bits  in  an 
' accumulator.  Program  control  instructions  include  several  types  of  jump  instructions  and 

the  subroutine  control  PUSHJ  and  POPJ  instructions. 

I Input/output  instructions  govern  all  direct  transfers  of  data  to  and  from  the  peripheral 

I equipment  and  also  perform  many  operations  within  the  processor.  Block  transfer 

instructions  handle  bulk  data  transfers  to/from  I/O  devices. 

The  KllO  has  hardware  for  processing  both  single-precision  and  double-precision 
floating-point  numbers.  There  are  eight  double-precision  instructions  and  three 
I fi.xed/ floating  conversion  instructions.  A double-precision  word  consists  of  the  sign,  an  8-bit 

I exponent  and  a 62-bit  fraction.  This  gives  a precision  in  the  fraction  of  1 part  in  4.6  x 10'  * 

. and  an  exponent  of  2 to  a power  of  from  -128  to  +127. 

2. 1.1. 1.2.2  Processor  Modes.  Instructions  on  the  DEC- 10  are  executed  in  one  of  two 
■ modes  depending  upon  whether  a mode  bit  has  been  set.  Programs  operate  in  either  User 

Mode  or  Executive  Mode.  In  Executive  Mode  operations,  all  implemented  instructions  are 
legal,  addresses  are  not  relocated,  and  all  core  locations  are  accessible.  The  monitor  operates 
in  Executive  Mode  and  is  able  to  control  all  system  resources  and  the  state  of  the  processor. 
In  User  Mode  operations,  addresses  are  relocated,  certain  instructions  are  illegal,  causing 
monitor  traps  when  executed,  and  address  references  are  confined  within  two  program  seg- 
ments. 

1 

The  KUO  further  divides  Executive  and  User  Mode  operation  into  two  submodes  each. 
User  Mode  is  subdivided  into  public  and  concealed  submodes  and  Executive  Mode  into 
supervisor  and  kernel  submodes.  For  each  512-word  page  in  the  system,  information  is 
stored  in  a table  maintained  by  the  operating  system  which  specifies  whether  a page  can  be 
accessed  or  altered,  and  if  it  is  defined  to  be  public  or  concealed.  The  Executive  and  User 


1 

H 


Modes  subdivide  on  the  KIIO  according  to  whether  the  active  program  is  running  in  a public 
or  concealed  area.  Within  User  Mode  are  the  public  and  concealed  submodes;  within 
Executive  Mode,  the  supervisor  and  kernel  submodes.  These  mode  features  are  summarized 
in  Table  2.1.1.1-4. 

2.1. 1,1. 2.3  Processor  Memory  Management.  The  KllO  provides  memory  address 
mapping  from  the  program’s  memory  address  space  (referred  to  as  the  effective  address)  to 
the  physical  memory  address  space  by  substitution  of  the  most  significant  bits  of  the 
memory  address.  This  mapping  provides  access  to  the  entire  physical  memory  space  which  is 
16  times  larger  than  the  maximum  user  address  space.  The  user’s  effective  address  space  is 
256K  words  addressed  with  18-bit  addresses;  the  physical  address  space  is  4,194,304  deci- 
mal. 

The  memory  mapping  process  utilizes  the  most  significant  nine  bits  of  the  effective 
address  as  an  index  into  the  appropriate  page  map  (User  or  Executive)  in  memory.  The  data 
located  by  the  index  provides  13  bits  which  are  appended  to  the  least  significant  9 bits  of 
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TABLE  2.1.1.14.  PROCESSOR  MOOES 


Uwr  Mode 


Public  Submode 


Concealed  Submode 


• User  programs  • Proprietary  programs 

• 256 K word  address  • Can  READ,  WRiTE, 

EXECUTE,  or  TRANS- 
FER to  any  location 
labeied  Pubiic 

• Ali  instructions  permitted  unless 
they  compromise  integrity  of 
system  or  other  users 

• Can  transfer  to  concealed  submode 
only  at  entry  points 


Executive  Mode  (Monitor) 


Supervisor  Submode 


Kernel  Submode 


• Performs  general  management  of  tystem 

• Performs  those  functions  that  affect 
one  user  at  a time 

• Executes  in  virtual  address  space 
labeled  Public 


• Performs  i/0  for  system 

• Performs  those  functions 
that  affect  all  users 
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the  effective  address  in  order  to  form  the  22  bit  physical  address.  Also  provided  are  three 
bits  which  indicate  what  type  of  memory  requests  are  allowed  to  the  page  in  question  (one, 
read-only,  proprietary,  etc).  If  this  scheme  were  implemented  exactly  as  outlined  above, 
every  user  memory  reference  would  require  two  actual  memory  references;  one  to  obtain 
the  memory  mapping  data  and  another  to  obtain  the  user’s  mapped  memory  reference.  In 
order  to  reduce  the  number  of  actual  memory  references  to  nearly  the  same  number  as 
required  by  the  program,  an  associative  memory  mapping  unit  is  used  in  the  KUO  as 
illustrated  by  Figure  2 i 1.1-2. 

The  Monitor  assigns  the  core  area  for  each  user  by  loading  the  various  page  tables, 
setting  up  the  trap  locations  in  the  user  page  map,  and  responding  appropriately  when  a trap 
occurs.  The  Monitor  provides  memory  protection  for  itself  and  each  user  by  filling  the  page 
tables  only  with  those  entries  which  are  allowed  to  be  accessed.  A zero  access  bit  in  the  page 
table  will  cause  reference  to  the  associated  page  to  initiate  a page  failure  trap  to  the 
Monitor.  The  TOPS-10  Operating  System  utilizes  the  KIIO  and  page  maps  to  create  one  or 
two  segment  programs.  The  major  benefits  of  the  paging  capability  are  a smaller  unit  of  core 
allocation  (512  words  instead  of  1,024),  the  freedom  to  scatter  the  pages  of  a segment 
randomly  throu^  physical  core  (avoiding  core  fragmentation  and  the  overhead  of  repacking 
core),  and  the  opportunity  to  execute  a program  when  all  of  its  pages  are  not  in  physical 
core  (i.e.,  a virtual  memory  capability). 

2. 1.1. 1.2.4  Real-Time  Clock.  The  DKIO  Real-Time  Clock  provides  high-resolution 
timekeeping  for  time  accounting,  time-base  maintenance,  periodic  high-frequency  inter- 
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WORDS 


EFFECTIVE  ADDRESS 


18  BITS 


22  BITS 


-[ 


2S6K  WORDS 
512  PAGES 


4096K  WORDS 
8192  PAGES 


PHYSICAL  ADDRESS 


Fi|art  2.1.1.1-2.  A84ra»  competition  tehonN  for  KIIO  procotsor. 
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rupts,  and  inUrval  timing.  The  clock  provides  110  jUs  resolution  and  a choice  of  up  to  2'  * 
possible  liming  intervals,  so  that  inU'rrupts  can  be  programmed  at  intervals  from  10  ps  up  to 
2.6  sec. 


In  addition  to  an  interval  register,  the  DKIO  has  a frequency  counter  which  counts  the 
pulses  of  an  internal  t 0.01  clock  kHz,  or  an  external  clock  having  a maximum  frequency  of 
400  kHz.  The  clock  also  includes  a comparator  network  which  provides  a running 
comparison  between  tlie  frequency  counter  and  the  interval  register.  When  the  frequency 
counter  reading  equals  the  total  on  the  interval  register,  a program  interrupt  is  generated  and 
the  frequency  counter  is  automatically  reset  so  that  it  can  time  the  next  interval. 

The  clock,  which  is  assignable  to  any  interrupt  channel,  can  be  used  to  pace  real  time, 
monitor,  or  other  functions  performed  in  either  Executive  or  User  Modes.  Clock  updating  is 
interlocked  with  the  DAT.AI  instructions  so  that  it  can  be  read  correctly  at  any  time  by  the 
KllO  without  losing  a clock  pulse. 

2.1. 1.1 .2.5  Fast  Register  Blocks.  General-purpose  registers  are  another  DEC-IO  feature 
that  help  improve  program  execution.  These  sets  of  fast  integrated  circuit  registers  can  be 
used  as  accumulators,  index  registers,  and  as  the  first  locations  in  memory.  Since  the 
regisU'rs  can  be  addressetl  as  memor>’  locations,  they  do  not  require  special  handling 
instructions.  Four  sets  of  16  fast  registers  are  included  in  the  KllO.  Program  switching  time 
for  the  KllO  between  register  stacks  is  2.5  jus.  On  the  KllO,  different  register  blocks  can  be 
used  for  the  operating  system  and  individual  users.  This  eliminates  the  need  for  storing 
register  contents  when  switching  from  User  Mode  to  Executive  Mode.  .Also,  a critical 
real-time  program  is  able  to  maintain  its  owm  register  block  for  handling  data  and  interrupt 
sequences  at  maximum  speed. 

2.1. 1.1.2. 6 Multiplexed  I/O  Bus.  The  DEC-10  Multiplexed  I/O  Bus  provides  a 36-bit 
full-word  parallel  path  between  memor>-  and  an  I/O  device  for  purposes  of  control  or 
low-speed  data  transfer.  To  initiate  high-spet'd  data  transmission  directly  between  memor\’ 
and  a device  connected  to  the  memory  bus.  a control  word  is  first  transferred  over  the  I/O 
bus  to  the  buffer  of  the  high-speed  device  controller.  Then,  on  command,  entire  data  blocks 
are  moved  directly  to  or  from  memory  with  a single  instruction. 

The  I/O  bus  may  also  be  u.sed  as  a control  and  data  path  to/from  a large  number  of 
low-speed  I/O  devices.  Transfer  is  performed  in  36-bit  words  in  parallel  at  speeds  of  370K 
words/s  on  the  KIIO.  Thus  each  data  transmission  instruction  moves  one  word  of  data 
between  memory  and  the  buffer  of  the  device  controller.  When  block  input  or  output 
instructions  are  used,  entire  blocks  of  data  are  moved  to  or  from  the  device  with  a .single 
instruction. 


2. 1.1. 2 Direct  Memory  Access  of  Simulators 


The  AVSAIL  laboratory  is  designed  to  facilitate  testing  of  hardware/software  systems  in 
a .simulated  real-world  environment.  The  systems  under  test  may  include  hardware  and 
software  only,  or,  alU'rnatively,  human  (pilot)  interaction  with  a simulated  external 
environment  may  be  included  as  a system  component.  An  example  might  be  the  testing  of  a 
fire  control  computer  and  its  software  with  a human  pilot  flying  in  a simulated  cockpit  as  he 
views  the  target  on  a computer  generated  display.  Fire  control  computer  and  software  are 
real,  but  the  aircraft  dynamics  and  the  target  display  must  be  simulated  with  the  proper 
time  relationships.  In  the  AVSAIL  laboratory,  the  DEC-10  computer  provides  the  simulated 
environment  by  executing  models  of  that  environment.  The  interface  betwetni  the  DEC-10 
and  the  sy.stem  under  test  is  provided  by  multiple  DEC  PDP-11  minicomputers  that  allow 
more  than  one  system  simulation,  or  complex  multicomputer  simulations,  to  be  connected 
simultaneously  to  the  DEC-10.  As  shown  in  Figure  1.3. 1.1-1,  tliere  arc  currently  eight 
PDP-H’s  interfaced  to  the  DEC-10.  Four  of  these  are  devoted  to  various  aspects  of  the 
DAIS  program,  one  is  devoted  to  interfacing  the  F-16  Fire  Control  Computer  Simulator, 
one  to  the  cockpit  simulator  currently  being  used  with  DAIS,  one  to  the  Evans  and  Suther- 
land Picture  System,  and  the  eighth  to  the  video  center. 

In  order  to  interface  multiple  PDP-ll’s  to  the  DEC-10,  hardware  and  software  features 
have  been  providwl  to  allow  the  PDP-ll’s  to  transmit  and  receive  data  from  the  DEC-10. 
The  basic  mechanism  for  data  communication  is  a 4K  word  memory  “window”  in  the 
DEC- 10  memory.  The  lo<'ation  of  the  window  can  be  specified  by  any  DEC-10  program  and 
addressed  by  the  PDP-11  computer.  Provision  for  an  18-bit  address  has  been  made  by 
hardware  modifications  to  the  DMA-IOC  Direct  Memory  Acce.ss  Controller.  The  memory 
“window”  is  formatted  to  provide  storage  of  “to”  and  "from”  data  and  window  identifier 
information.  Data  are  stored  in  the  window  at  each  simulation  frame  or  upon  interrupt  from 
a PDP-11.  Data  transfer  to  and  from  the  PDP-11  is  under  PDP-11  control. 

A special  software  program,  resident  in  the  DEC-10,  handles  data  formatting  as  required 
by  the  different  word  sizes  of  the  two  computers  (i.e.,  3G  bits  for  the  DEC-10  and  18  bits 
for  the  PDP-11).  This  .software  also  provides  the  functions  of  interrupt  handling  from  the 
PDP-ll’s  and  the  real-time  clock. 

2.1. 1.3  PDP-11  Satellite  Computers 

Eight  Digital  Equipment  Conioration  (DEC)  PDP-11  computers  are  employed  within  the 
DEC-10  Host  Simulation  Processor  Hardware  in  order  to  provide  an  interface  for  each  of 
eight  system  simulators  with  the  Host  Hardware.  Each  interface  is  o[>erated  in  a pseudo 


real-time  asynchronous  interrupt  mode  via  a Direct  Memory  Interface  Controller.  The 
output  of  the  memory  controller  is  coupled  to  an  MX-10  Memory  Multiplexer  prior  to 
connection  to  the  DEC-10  memory  bus.  The  speed  of  the  multiplexer  and  direct  memory 
access  bus  operation  is  fast  enou^  that  each  satellite  computer  appears  to  be  operating  in 
real  time  to  the  user.  Each  system  simulator  computer  can  in  this  manner  provide  data  to 
common  memory  blocks  of  the  DEC-10  system.  This  data  can  then  be  shared  throughout 
the  facility.  The  assignment  of  simulator  processors  is  given  in  Table  2.1.1.3-1. 

The  PDP-11  series  of  computers  are  well  suited  to  use  in  a simulation  facility  primarily 
due  to  their  single  or  UNIBUS  structure.  The  UNIBUS  is  a single,  high-speed,  bidirectional, 
asynchronous  communications  path  within  each  of  the  PDP-11  computers.  It  allows  all 
system  components  and  peripheral  devices  to  communicate  directly  without  central 
processor  intervention.  This  direct  communications  means  that  the  PDP-11  does  not  require 
I/O  instructions.  The  same  instruction  that  performs  a register-to-register  transfer  within  the 
central  processor  performs: 

1.  a memory-to-device-register  transfer, 

2.  a memory-to-memory  transfer, 

3.  a device-register-to-memory  transfer,  and 

4.  a device-register-to-another-device-register  transfer. 

Therefore,  the  key  point  is  that  a peripheral  device  can  be  communicating  with  memory 
at  the  same  time  the  processor  is  performing  computational  operations. 

All  PDP-11  system  elements  connect  directly  to  the  UNIBUS  in  plug-in  fashion.  The 
asynchronous  nature  of  the  UNIBUS  means  external  devices  can  be  tied  into  the  system 
without  regard  for  individual  operating  speed.  The  UNIBUS  permits  system  expansion  to 
any  level  without  revision  of  the  present  system.  Also,  as  the  full  UNIBUS  technique  is 


TABLE  2.1.1.3-1.  PDP-11  PROCESSOR  ASSIGNMENTS 


Syitem  Simulator 


a)  DAIS  (GT-44A,  Figure  2.1.1.3-1) 

b)  DAIS  (6T-44A,  Figure  2.1.1.3-1) 

c)  DAIS  (6T-44B,  Figure  2.1.1.3-2) 

d)  DAIS  (GT-44C,  Figure  2.1.1.3-3) 


PDP  Computer 


System  Simulator 


PDP  Computer 


e)  FI 6 Simulator 

f)  Cockpit 

g)  Evans  and  Sutherland  Picture  System 

h)  Video  Center 
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common  to  all  PDP-11  systems,  peripheral  devices  can  be  freely  interchanged  from  system 
to  system  without  the  need  for  special  interfaces. 


All  PDP-11  processors  use  the  same  basic  instruction  set.  Programs  developed  on  the 
PDP-11/40  of  DAIS  are  immediately  usable  on  the  PDP-11/50  of  the  Picture  System. 
Common  software  incurs  no  conversion  problems  as  needs  increase.  Programs  developed  on 
any  PDP-11  will  serve  all  anticipated  systems,  regardless  of  the  specific  model.  A processor 
comparison  table  for  the  11/40, 11/45, 11/50,  and  11/20  is  given  in  Table  2.1. 1.3-2. 


2.1. 1.3.1  The  DAIS  simulators 


The  four  PDP  11/40  computers  associated  with  DAIS  are  employed  as  shown  in  Figures 
2.1. 1.3-1,  -2,  and  -3.  Two  of  the  simulators  have  configuration  A shown  in  Figure  2.1. 1.3-1. 


TABLE  2.1.1.3-2.  PDM1  PROCESSOR  COMPARISON  TABLE 


Processor  Type 

11/20 

11/40 

If/45 

ft /so 

StKk  processing 

Yes 

Yes 

Yes 

Yes 

Programmable  stack  limit 

No 

Optional 

Yes 

Yes 

General  registers 

8 

8 

16 

16 

Rag-to-rag.  transfer 

2.3  Ml 

900  ns 

300  ns 

300  ns 

Hardware  floating  point 

No 

32  bit  (opt) 

32, 64  bit  (opt) 

32, 64  bit  (opt) 

Max  memory  size  (bytas) 

56K 

248K 

248K 

248K 

Memory  type 

Core 

Core 

BIPOLAR* 

BIPOLAR 

MOS* 

MOS 

Core 

Core 

Effective  memory  speed 

980  ns 

1000  ns 

300  ns 

300  ns 

500  ns 

500  ns 

1000  ns 

1000  ns 

Memory  parity 

Optional 

Yes 

Yes 

Yes 

Memory  management 

No 

Optional 

Yes 

Yes 

Processing  modes 

1 

2 (opt) 

3 

3 

Auto  hardware  interrupts 

Yas 

Yet 

Yes 

Yes 

Auto  software  interrupts 

Yas” 

No 

Yes 

Yes 

Power  faU/auto  restart 

Yes 

Yes 

Yes 

Yes 

Real-time  clock 

Optional 

Optional 

Yes 

Yes 

Progremnwr's  console 

Yes 

Yes 

Yes 

Yes 

Hardwere  bootstrap 

Optional 

Optional 

Yes 

Yes 

Serial  line  controller 

Yes 

Yes 

Yes 

Yes 

*A  POP  tt/4S  uMd  with  BIPOLAR  and/or  MOS  memory  becomes  the  equivalent  of  a POP  1 1/SO. 
‘'Automatic  interrupts  are  possible  through  the  use  of  software  TRAP  programming. 
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Figure  2.1.1.3-3.  DAIS  simuletor  (GT-44  C). 


This  configuration  utilizes  16K  of  16-bit  core  memory  as  well  as  2 1.2  megaword  disk 
memory  systems.  Configuration  B shown  in  Figure  2.1. 1.3-2  employs  32K  of  16-bit  core 
memory,  2 1.2  megaword  disk  drives  and  a bootstrap  loader  memory.  Configuration  C 
shown  in  Figure  2.1. 1.3-3  contains  only  16K  of  16-bit  core  memory,  however,  it  also 
utilizes  2 1.2  megaword  disk  drives. 

2.1. 1.3.2  The  FI 6 simulator 

A PDF  11/40  computer  is  used  with  the  F16  simulator  as  shown  in  Figure  2.1.1.3-4.  The 
basic  memory  provided  for  this  configuration  consists  of  a 24K  word  by  16-bit  core 
memory,  and  a 1.2  megaword  disk  memory  system.  The  11/40  is  used  in  this  simulator  in 
order  to  control  the  Fire  Control  Navigation  Panel,  and  Fire  Control  Computer  simulator.  It 
also  receives  Flight  Control  Stick  and  Throttle  data  as  inputs  and  provides  control  informa- 
tion to  a local  Head  Up  Display  CRT. 

2.1. 1.3.3  The  cockpit  simulator 

The  cockpit  simulator  utilizes  a PDP  11/45  as  shown  in  Figure  2. 1.1. 3-5.  In  this 
configuration  a high-speed  28K  by  16-bit  MOS  memory  as  well  as  a 68K  word  by  16-bit 
core  memory  are  used.  The  11/45  processor  provides  control  and  data  for  the  Horizontal 
Situation  Display  and  Vertical  Situation  Display  as  well  as  the  control  stick  and  associated 
lamp  and  keyboard  displays.  These  controls  and  displays  are  all  located  within  the  simulated 
cockpit. 

2. 1.1. 3.4  The  Picture  System 

The  Picture  System  may  be  interfaced  and  controlled  by  any  PDP-11  computer.  Picture 
Systems  have  been  interfaced  to  PDP-11/05,  PDP-11/35  and  PDP-11/45  computers  with 
various  standard  DEC  peripherals  including  disks,  DECtapes,  megtapes,  printers,  etc.  The 
standard  Refresh  Buffer  requirements  is  8K  of  36-bit  words.  An  additional  8K  of  Refiresh 
Memory  may  be  obtained  to  provide  a 16K  Refresh  Buffer. 

The  Picture  System  currently  employs  a PDP-11/50  as  shown  in  Figure  2. 1.1. 3-6.  In  this 
configuration,  two  core  memories  of  16K  and  44K  each  are  utilized  as  well  as  32K  of  MOS 
memory. 

2.1. 1.3.5  The  Video  Center 

The  Video  Center  currently  employs  a PDP-11/20  as  shown  in  Figure  2. 1.1. 3-7.  This 
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Figure  2.1. 1.3-4.  F-1 6 simulator. 


Figure  2.1.1.3-S.  The  cockpit  amulator. 


Figure  Z1.1.3-6.  The  Picture  System  simuletor. 
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1 configuration  employs  only  28K  of  16-bit  core  memory  as  the  11/20  is  used  primarily  to 

{ 2.1.2  OEC$y$tem-10  Software 

2. 1.2.1  Features  and  Operating  System 
Ij  2.1. 2.1.1  Features 

The  wide  variety  of  computing  requirements  demanded  by  the  several  classes  of 
i j simulations  carried  out  within  the  AVSAIL  laboratory  are  satisfied  by  the  flexibility  and 

i 

scope  of  the  DEC-10  software  package.  This  software  package  provides  for  the  concurrent 
operations  of  timesharing,  multistream  batch,  real  time,  and  remote  communications.  These 
multifunction  capabilities  allow  multiple  uses,  both  at  AFAL  and  at  remote  locations,  to 
perform  all  of  the  tasks  necessary  to  create  new  simulations,  modify  existing  simulations, 
I and  run  those  simulations  as  if  they  were  individual  users.  The  number  of  users  on  the 

i system  at  any  one  time  depends  on  the  total  computing  load. 

From  the  user’s  viewpoint,  the  DEC-10  may  be  thought  of  in  terms  of:  (1)  his  input 
( device  and  software  which  he  has  written  or  which  act  on  his  software,  as  in  Figure 

I 2.1. 2. 1-1;  (2)  the  operating  system  software  whicli  controls  system  resources;  and  (3)  the 

I 


Figure  2.I.2.M.  DECsysttnvIO.  u$«r*$  vim  | 
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system  hardware  which  was  previously  described.  The  DEC-10  has  several  capabilities  which 
increase  the  utilization  of  system  resources  in  a multiuser  environment.  These  are  described 
in  the  following  three  sections. 


2.1. 2. 1.1.1  Timesharing.  The  timesharing  capability  allows  resources  to  be  shared 
among  users.  The  timesharing  environment  utilizes  processor  time  and  system  resources  that 
are  wasted  in  single-user  systems.  Users  are  not  restricted  to  a small  set  of  system  resources, 
but  instead  are  provided  with  the  full  variety  of  facilities.  By  means  of  his  terminal,  the  user 
has  online  access  to  most  of  the  system’s  features.  This  online  access  is  available  through  the 
operating  system  command  control  language,  which  is  the  means  by  which  the  timesharing 
user  communicates  with  the  system. 

Through  the  command  language,  the  user  controls  the  running  of  a task,  or  job,  to 
achieve  the  desired  results:  create,  edit,  and  delete  files;  start,  suspend,  and  terminate  a job;  i 

compile,  execute,  and  debug  a program.  In  addition,  since  multiprogramming  batch  software 
accepts  the  same  command  language  as  the  timesharing  software,  any  user  can  enter  a 
program  into  the  batch  run  queue.  Thus,  any  timesharing  terminal  can  act  as  a remote 
job-entry  terminal. 

With  the  command  language,  the  user  can  also  request  assignment  of  any  peripheral 
device  (magnetic  tape,  DECtape,  and  private  disk  pack)  for  exclusive  use.  When  the  request 
for  assignment  is  received,  the  operating  system  verifies  that  the  device  is  available  to  this 
user,  and  the  user  is  granted  its  private  use  until  he  relinquishes  it.  In  this  way,  the  user  can 
also  have  complete  control  of  devices  such  as  card  readers  and  punches,  paper  tape  readers 
and  punches,  and  line  printers. 

When  private  assignment  of  a slow-speed  device  (card  punch,  line  printer,  paper  tape 
punch,  and  plotter)  is  not  required,  the  user  can  employ  the  spooling  feature  of  the 

operating  system.  Spooling  is  a method  by  which  output  to  a slow-speed  device  is  placed  on  | 

a high-speed  disk  or  drum.  This  technique  prevents  the  user  from  consuming  unnecessary  j 

time  and  space  in  core  while  waiting  for  either  a device  to  become  available  or  output  to  be  j 

completed.  In  addition,  the  device  is  managed  to  a better  degree  because  the  users  cannot  tie  J 

it  up  indefinitely,  and  the  demand  fluctuations  experienced  by  these  devices  are  equalized.  j 

j 

2.1.2.1.1.2  Multiprogramming.  The  DEC-10  has  the  capability  to  make  maximum  J 

utilization  of  memory.  The  DEC-10  is  a multiprogramming  system;  i.e.,  it  allows  multiple  ' 

independent-user  programs  to  reside  simultaneously  in  memory  and  to  run  concurrently.  j 


This  technique  of  sharing  memory  and  processor  time  enhances  the  efficient  operation  of 
the  system  by  switching  the  processor  from  a program  that  is  temporarily  .stopped  becau.se 
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of  I/O  transmission  to  a program  that  is  executable.  When  core  and  the  processor  are  shared 
in  this  manner,  each  user’s  program  has  a memory  area  distinct  from  the  area  of  other  users. 

Any  attempt  to  read  or  change  information  outside  of  the  area  a user  can  access 
immediately  stops  the  program  and  notifies  the  operating  system.  Because  available  memory 
can  contain  only  a finite  number  of  programs  at  any  one  time,  the  computing  system 
employs  a secondary  memory,  usually  disk  or  drum,  to  increase  the  number  of  users 

serviced.  User  programs  exist  on  the  secondary  memory  and  move  into  memory  for  j 

execution.  Programs  in  memory  exchange  places  with  the  programs  being  transferred  from  ] 

secondary  memory  for  maximum  use  available  main  memory.  Because  the  transferring,  or  | 

swapping,  takes  place  directly  between  main  memory  and  the  secondary  memory,  the  I 

central  processor  can  be  operating  on  a user  program  in  one  part  of  memory  while  swapping  ' f 

is  taking  place  in  another.  This  independent,  overlapped  operation  greatly  improves  system 
utilization  by  increasing  the  number  of  users  that  can  be  accommodated  at  the  same  time. 

To  further  increase  the  utilization  of  memory,  the  operating  system  allows  users  to  share 
the  same  copy  of  a program  or  data  segment.  This  prevents  the  excessive  memory  usage  that 
results  when  a program  is  duplicated  for  several  users.  A program  that  can  be  shared  is  called 
a reentrant  program  and  is  divided  into  two  parts  or  segments.  One  segment  contains  the 
code  that  is  not  modified  during  execution  (e.g.,  compilers  and  assemblers)  and  can  be  used 
by  any  number  of  users.  The  other  segment  contains  nonreentrant  code  and  data.  The 
operating  system  provides  for  shared  segments  to  guarantee  that  they  are  not  accidentally 
modified. 

2.1.2.1.1.3  File  Protection.  The  DEC-10  has  the  capability  to  manage  the  storage  of 
user  program  and  data  files  consistent  with  the  multiple-user  environment.  The  mass  storage 
devices  available  are  shared  iunong  users,  and  thus,  the  operating  system  must  ensure 
independence  among  the  users;  one  user’s  actions  must  not  affect  the  activities  of  another 
unless  the  users  desire  to  work  together.  To  guarantee  such  independence,  the  operating 
system  provides  a file  system  for  disks,  disk  packs,  and  drums.  Each  user’s  data  is  organized 
into  groups  of  128-word  blocks  called  files.  The  user  gives  a name  to  each  of  his  files,  and 
the  list  of  these  names  is  kept  by  the  operating  system  for  each  user.  The  operating  system  is 
then  responsible  for  protecting  each  user’s  file  storage  from  intrusion  by  unauthorized  users. 

The  operating  system  lets  the  user  specify  protection  rights,  or  codes,  for  his  files.  These 
codes  designate  if  others  may  read  the  file,  and  after  access,  if  the  files  can  be  modified  in 
any  way.  Files  are  assigned  protection  levels  for  each  three  classes  of  users:  self,  users  with  a 
common  project  number,  and  all  users.  Each  user  class  may  be  assigned  a different  access 
privilege,  so  that  there  are  eight  levels  in  each  of  the  three  user  classes  as  described  by  Table 
2.1. 2. 1-1.  This  file  protection  scheme  results  in  a three-digit  access  code  for  all  files. 
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TABLE  2.U.M.  FILE  FROTECTION  CODES 


Protvction  Ltvtl 

Accnt  Codt 

Acctn  Privitign 

Graattrt  prottction 

7 

No  KCt0  priviltgM 

6 

EXECUTE  ONLY 

5 

READ, EXECUTE 

4 

APPEND,  READ, EXECUTE 

3 

UPDATE,  APPEND,  READ 
EXECUTE 

2 

WRITE,  UPDATE,  APPEND, 
READ, EXECUTE 

1 

RENAME,  WRITE,  UPDATE, 
APPEND, READ, EXECUTE 

LtHt  prottction 

0 

CHANGE  PDSITIDN,  RENAME, 
WRITE,  UPDATE,  APPEND, 
READ, EXECUTE 

2.1.2.1.2  Operating  system 

In  order  to  have  some  better  avipreeiation  for  the  manner  in  which  the  resouri'es  of  the 
DKC-IO  are  manaRed,  it  is  helpful  to  examine  the  nature  of  the  ovierating  system  alluded  to 
by  FiRure  2.1. 2.1-1.  The  resident  operatinR  system  is  made  up  of  a number  of  separate  and 
.somewhat  independent  parts,  or  routines  (FiRure  2. 1.2.1-*’).  Some  of  these  routines  are 
cyclic  in  nature  and  are  repeatt'd  at  every  system  clock  inU'irupt  (tick)  to  ensure  that  every 
u.ser  of  the  computinR  system  is  receivinR  the  requested  services.  These  cyclic  routines  ar*': 

1.  The  command  processor,  or  decoder, 

2.  The  schedider, 

;i.  'The  swapper. 

Hie  command  tlecoder  is  responsible  for  interpretinR  commands  typed  by  the  user  on 
h»i  terminal  and  passiuR  them  to  the  appropriate  system  proRram  or  routine.  The  scheduler 
(.-•  Mle^  whu  h user  is  to  run  in  the  interval  between  the  clock  interrupts,  allocates  sharable 
» .1.  .1.  resources,  .out  saves  and  restoo's  conditions  nee<l(-d  to  start  a proRram  interrupteil  by 
• I.  . k fh.-  sw;ip|<er  rotates  us»*r  jobs  la'twiH'u  .secondary  disk  memory  and  com  memory 
• ..  .<«.(  •hti  h |ol>s  should  lie  in  core  but  are  not.  These  routines  constitute  the  part  of 
. ■ .1  % .i.  in  ih.ii  illows  inanv  lolis  to  tie  ojieratiiiR  simultaneously, 

■»  ..(H-r  iiimt  system  ere  invoked  only  by  user  pro:.n-ams  and 


Figurt  2.1. 2.1-2.  Tilt  rtsidtnl  optriting  lysnm. 


an'  n'.'ipon.'iiblo  f<ir  proviiiinu  tlu'sc  protP'ams  witli  thi'  soiTioi'.^  availal'U’  throiinli  llio 
ojH'rat.inn  sysU'in.  'llioso  rouUni's  an'; 

1.  Tlip  Uninipli'nu'nU'il  Usor  (Iplion  (UlUl), 

2.  'Hn*  input /output  rout.iiu'.>«, 

.'1.  Tlu'  filo  handler. 

Tlu*  UIKT  hamilor  i.i  the  inoan.s  by  whioli  tlio  usi'r  proijraiu  ooinmunii’atos  with  t.lu' 
opomtiuK  .sy.sloin  in  ontor  to  bavo  a .sorvii’n  jH'rfornu'd.  ('oinnuinioalion  is  liy  way  of 
pro)tramm«'<t  ojH’rators  (also  known  as  UlKI's)  oontaiiu'd  in  tho  u.sor  proifiiun  whii’li,  wbon 
pxooub'it.  go  to  tbo  oin'rating  systoin  for  pnnv.ssing.  Ttu'  input /out|>ut  routim’s  am  tlu' 
routiiu's  n'sponsibh'  for  din'oting  data  Ininsfors  Ix'twivn  poriplroral  dovioos  aiut  usi'r 


prof.'T.itns  in  core  memory.  These  routines  are  invoked  through  the  UUO  handler,  thus  saving 
the  user  the  detailed  programming  needed  to  control  peripheral  devices.  The  file  handler 
adds  |x*rmanent  user  storage  to  the  computing  system  by  allowing  users  to  store  named 
programs  and  data  as  files. 

2.1. 2. 1.2.1  Command  Decoder.  The  Command  Decoder  is  the  communications  link 
iH'tween  the  user’s  terminal  and  the  operating  system.  Because  all  the  requests  for  system 
resources  are  initiatt'd  via  the  command  decoder,  it  is  the  most  visible  part  of  the  system  to 

each  user.  When  the  ust'r  types  commands  and/or  requests  on  his  terminal,  tlie  characters  are  j 

si  'rf.l  in  an  input  buffer  in  the  operating  system.  The  command  decoder  examines  these 
. lers  in  the  buffer,  checks  them  for  correct  syntax,  and  invokes  the  system  program  or 
user  program  as  specified  by  the  command. 


Dll  each  clock  interrupt,  control  is  given  to  the  command  decoder  to  interpret  and 
process  one  command  in  the  input  buffer.  Given  that  the  command  is  a legal  one,  several 
I actions  are  pos.sible.  For  instance,  a command  must  be  delayed  if  the  job  is  swapped  out  to 

1 the  disk  and  the  command  requires  that  the  job  be  resident  in  core;  the  command  is 

^ executed  on  a later  clock  interrupt  when  the  job  is  back  in  core.  If  all  conditions  as  specified 

by  the  legality  flags  are  met,  control  is  passed  to  the  appropriate  program. 

2.1.2.1.2.2  Scheduler.  The  DKC-10  is  a multiprogramming  system;  i.e.,  it  allows  several 
user  jobs  to  reside  in  core  simultaneously  and  to  operate  sequentially.  It  is  then  the  job  of 
the  scheduler  to  decide  which  jobs  should  run  at  any  given  time.  In  addition  to  the 
multiprogramming  feature,  the  DfilC-lO  employs  a swapping  technique  whereby  jobs  can 
exist  on  an  external  storage  device  (e.g.,  disk  or  drum)  as  well  as  in  core.  Therefore,  the 
.scheduler  decides  not  only  what  job  is  to  be  run  next,  but  also  when  a job  is  to  be  swapped 
out  onto  disk  or  drum  and  later  brought  back  into  core. 

All  jobs  in  the  .system  are  retained  in  ordered  groupings  called  queues.  Thest'  queues 
have  various  priorities  that  reflect  the  status  of  each  job  at  any  given  moment.  The  queue  in 
. which  a job  is  placed  depends  on  the  system  resourt'e  for  which  it  is  waiting  and,  because  a 

job  can  wait  for  only  one  resource  at  a time,  it  can  be  in  only  one  queue  at  a time.  Several 
of  the  po.ssible  queues  in  the  system  are: 

1.  Run  queues  for  jobs  waiting  for,  or  jobs  in,  exeinition, 

2.  I/O  wait  queues  for  jobs  waiting  for  data  transfers  to  be  completed, 

3.  I/O  wait-satisfied  queues  for  jobs  waiting  to  run  after  data  transfers  have  been 
completed, 
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4.  Resource  wait  queues  for  jobs  waiting  for  some  system  resource, 

5.  Null  queue  for  all  job  numbers  that  are  not  currently  being  used. 


The  job’s  position  within  certain  queues  determines  the  priority  of  the  job  \yith  respect 
to  other  jobs  in  the  same  queue.  For  example,  if  a job  is  first  in  the  queue  for  a sharable 
device,  it  has  the  highest  priority  for  the  device  when  it  becomes  available.  However,  if  a job 
is  in  an  I/O  wait  queue,  it  remains  in  the  queue  until  the  I/O  is  completed.  Therefore,  in  an 
I/O  wait  queue,  the  job’s  position  has  no  significance.  The  status  of  a job  is  changed  each 
time  it  is  placed  into  a different  queue. 

In  additon,  data  transfers  use  the  scheduler  to  permit  the  user  to  overlap  computation 
with  data  transmission.  In  unbuffered  data  modes,  the  user  supplies  an  address  of  a 
command  list  containing  pointers  to  locations  in  his  area  to  and  from  which  data  is  to  be 
transferred.  When  the  transfer  is  initiated,  the  job  is  scheduled  into  an  I/O  wait  queue  where 
it  remains  until  the  device  signals  the  scheduler  that  the  entire  transfer  has  been  completed. 

In  buffered  modes,  each  buffer  contains  information  to  prevent  the  user  and  the  device 
from  using  the  same  buffer  at  the  same  time.  If  the  user  requires  the  buffer  currently  being 
used  by  the  device  as  his  next  buffer,  the  user’s  job  is  scheduled  into  an  I/O  wait  queue. 
When  the  device  finishes  using  the  buffer,  the  device  calls  the  scheduler  to  reactivate  the  job. 

2. 1.2. 1.2.3  Swapper.  The  swapper  is  responsible  for  keeping  in  core  the  jobs  most 
likely  to  be  run.  It  determines  if  a job  should  be  in  core  by  scanning  the  various  queues  in 
which  a job  may  be.  If  the  swapper  decides  that  a job  should  be  brought  into  core,  it  may 
have  to  take  another  job  already  in  core  and  transfer  it  to  secondary  memory.  Therefore, 
the  swapper  is  not  only  responsible  for  bringing  a job  into  core  but  also  responsible  for 
selecting  the  job  to  be  swapped  out.  The  swapper  periodically  checks  to  see  if  a job  should 
be  swapped  in.  If  there  is  no  such  job,  then  it  checks  to  see  if  a job  is  requesting  more  core. 
If  there  is  no  job  wishing  to  expand  its  size,  then  the  swapper  does  nothing  further  and 
relinquishes  control  of  the  processor  until  the  next  clock  tick. 

2.1.2.1.2.4  UUO  Handler.  The  UUO  handler  is  responsible  for  accepting  requests  for 
services  available  through  the  operating  system.  These  requests  are  made  by  the  user 
program  via  software-implemented  instructions  known  as  programmed  operators,  or  ITlOs. 
The  UUO  handler  is  the  only  means  by  which  a user  program  can  give  control  to  the 
operating  system  in  order  to  have  a service  performed.  The  user  informs  the  otx'rating 
system  of  his  requirements  for  I/O  by  means  of  UUO's  contained  in  his  program.  The  actual 
input/output  routines  needed  are  then  called  by  the  UUO  handler. 
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2. 1.2. 1.2. 5 Input/Output  Since  the  operating  system  channels  communication 
between  the  user  and  the  device,  the  user  does  not  need  to  know  all  the  peculiarities  of  each 
device  on  the  system.  In  fact,  the  user  program  can  be  written  in  a similar  manner  for  all 
devices.  The  operating  system  will  ignore,  without  returning  an  error  message,  operations 
that  are  not  pertinent  to  the  device  being  used.  Thus,  a terminal  and  a disk  file  can  be 
processed  identically  by  the  user  program.  In  addition,  user  programs  can  be  written  to  be 
independent  of  any  particular  device.  The  operating  system  allows  the  user  program  to 
specify  a logical  device  name,  which  can  be  associated  with  any  physical  device  at  the  time 
when  the  program  is  to  be  executed.  Because  of  this  feature,  a program  that  is  coded  to  use 
a specific  device  does  not  need  to  be  rewritten  if  the  device  is  unavailable.  The  device  can  be 
designated  as  a logical  device  name  and  assigned  to  an  available  physical  device  with  one 
command  to  the  operating  system. 

2.1.2.1.2.6  File  Handler.  The  disk  file  handler  manages  user  and  system  data;  thus,  this 
data  can  be  stored,  retrieved,  protected,  and/or  shared  among  other  users  of  the  computing 
system.  All  information  in  the  system  is  stored  as  named  files  in  a uniform  and  consistent 
fashion,  thus  allowing  the  information  to  be  accessed  by  name  instead  of  by  physical  disk 
addresses.  Therefore,  to  reference  a file,  the  user  does  not  need  to  know  where  the  file  is 
physically  located.  A named  file  is  uniquely  identified  in  the  system  by  a file  name  and 
extension,  an  ordered  list  of  directory  names  (UFDs  and  SFDs)  which  identify  the  owner  of 
the  file,  and  a file  structure  name  which  identifies  the  group  of  disk  units  containing  the  file. 

Usually  a complete  disk  system  is  composed  of  many  disk  units  of  the  same  and/or 
different  types.  Therefore,  the  disk  system  consists  of  one  or  more  file  structures— a logical 
arrangement  of  files  on  one  or  more  disk  units  of  the  same  type.  This  method  of  file  storage 
allows  the  user  to  designate  which  disk  unit  of  the  file  structure  he  wishes  to  use  when 
storing  files.  Each  file  structure  is  logically  complete  and  is  the  smallest  section  of  file 
memory  that  can  be  removed  from  the  system  without  disturbing  other  units  in  other  file 
structures.  All  pointers  to  areas  in  a file  structure  are  by  way  of  logical  block  numbers  rather 
than  physical  disk  addresses;  there  are  no  pointers  to  areas  in  other  file  structures,  thereby 
allowing  the  file  structure  to  be  removed. 

All  disk  files  are  composed  of  two  parts,  data  and  information  used  to  retrieve  data.  The 
retrieval  part  of  the  file  contains  the  pointers  to  the  entire  file,  and  is  stored  in  two  distinct 
locations  on  the  device  and  accessed  separately  from  the  data.  System  reliability  is  increased 
with  this  method  because  the  probability  of  destroying  the  retrieval  information  is  reduced; 
system  performance  is  improved  because  the  number  of  positionings  needed  for 
random-access  methods  is  reduced.  The  storing  of  retrieval  information  is  the  same  for  both 
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sequential  and  random-access  files.  Thus  a file  can  be  created  sequentially  and  later  read 
randomly,  or  vice  versa,  without  any  data  conversion. 

To  the  user,  a file  structure  is  like  a device;  i.e.,  a file  structure  name  or  a set  of  file 
structure  names  can  be  used  as  the  device  name  in  command  strings  or  UUO  calls  to  the 
operating  system.  Although  file  structures  or  the  units  composing  the  file  structures  can  be 
specified  by  their  actual  names,  most  users  specify  a general,  or  generic,  name  (DSK)  which 
will  cause  the  operating  system  to  select  the  appropriate  file  structure.  The  appropriate  file 
structure  is  determined  by  a job  search  list.  Each  job  has  its  own  job  search  list  with  the  file 
structure  names  in  the  order  in  which  they  are  to  be  accessed  when  the  generic  name  is 
specified  as  the  device.  This  search  list  is  established  by  LOGIN  and  thus  each  user  has  a 
UFD  for  his  project-programmer  number  in  each  file  structure  in  which  LOGIN  allows  him 
to  have  files.  File  storage  is  dynamically  allocated  by  the  file  handler  during  program 
operations,  so  the  user  does  not  need  to  give  initial  estimates  of  file  length  or  the  number  of 
files. 

2.1.2.1.3  Real-time  operating  system  features 

The  multiple  simulators  attached  to  the  DEC-10  (Figure  1.3. 1.1-1)  which  require 
software  simulations  to  be  carried  out  by  the  DEC-10  in  real  time,  as  well  as  handle  the 
attendant  data  transfer  between  the  DEC-10  and  the  PDP-lls,  call  upon  the  real-time 
capabilities  of  the  operating  system.  The  operating  system  must  allocate  system  resources 
dynamically  in  order  to  satisfy  the  response  and  computational  requirements  of  real  time 
without  affecting  the  simultaneous  operations  of  timesharing  and  batch  jobs.  As  part  of  its 
normal  operation,  the  DEC-10  operating  system  satisfies  this  response  requirement  by 
overlapping  I/O  operations  with  processing  time  and  by  reacting  to  a constantly  changing 
system  load. 

At  the  same  time,  each  user  of  the  computing  system  must  be  protected  from  other 
users,  just  as  the  system  itself  is  protected  from  all  user  program  errors.  In  addition,  since 
real-time  systems  have  special  real-time  devices  associated  with  jobs,  the  computing  system 
must  be  protected  from  hardware  faults  that  could  cause  system  breakdown.  And,  because 
protection  is  part  of  the  function  of  the  operating  system,  the  real-time  software  employs 
this  feature  to  protect  users  as  well  as  itself  against  hardware  and  software  failures.  Inherent 
in  the  operating  system  is  the  capability  of  real  time,  and  it  is  by  way  of  calls  to  the 
operating  system  that  the  user  obtains  real-time  services.  The  services  obtained  by  calls 
within  the  user’s  program  include: 


1.  Locking  a job  in  core. 


2.  Connecting  a real-time  device  to  the  priority  interrupt  system, 

3.  Placing  a job  in  a high-priority  run  queue, 

4.  Initiating  the  execution  of  FORTRAN  or  machine  language  code  on  receipt  of  an 
interrupt, 

5.  Disconnecting  a real-time  device  from  the  priority  interrupt  system. 

Memory  space  may  be  occupied  by  the  resident  operating  system  and  by  a mix  of 
real-time  and  non-real-time  jobs.  The  only  fixed  partition  is  between  the  resident  operating 
system  and  the  remainder  of  memory.  A real-time  job  may  need  to  be  in  memory  so  as  not 
to  lose  information  when  its  associated  real-time  device  interrupts  (since  there  may  not  be 
sufficient  time  to  swap-in  the  job).  The  job  can  request  that  it  be  locked  into  core. 

The  real-time  user  can  connect  real-time  devices  to  the  priority  interrupt  system, 
respond  to  these  devices  at  interrupt  level,  remove  the  devices  from  the  interrupt  system, 
and/or  change  the  priority  interrupt  level  on  which  these  devices  are  assigned.  There  is  no 
requirement  that  these  devices  be  connected  at  system  generation  time.  The  user  specifies 
both  the  names  of  the  devices  generating  the  interrupts  and  the  priority  levels  on  which  the 
devices  function.  The  operating  system  then  links  the  devices  to  the  operating  system. 

The  real-time  user  can  receive  faster  response  by  placing  jobs  in  high-priority  run  queues. 
These  queues  are  examined  before  all  other  queues  in  the  computing  system,  and  any 
runnable  job  in  high-priority  queue  is  executed  before  jobs  in  other  queues.  In  addition,  jobs 
in  high-priority  queues  are  not  swapped  to  secondary  memory  until  all  other  queues  have 
been  scanned. 

2.1.2.1.4  Remote  communications 

The  DEC-10  allows  the  simultaneous  operation  of  multiple  remote  stations.  Software 
provisions  differentiate  one  remote  station  from  another.  By  utilizing  peripheral  devices  at 
various  stations,  the  user  is  provided  with  increased  capabilities  as  shown  in  Figure  2. 1.2. 1-3. 
For  example,  data  can  be  collected  from  various  remote  stations,  compiled  and  processed  at 
the  central  station,  and  then  the  results  of  the  processing  can  be  sent  to  all  contributors  of 
the  data. 

2. 1.2. 1.5  Batch  computing 

In  addition  to  the  timesharing  and  real-time  capabilities  available  on  the  DEC-10,  batch 
computing  is  provided  by  the  GALAXY-10  batch  software.  GALAXY-10  batch  software 
enables  the  DEC-10  to  execute  up  to  128  batch  jobs  concurrently  with  timesharing  jobs. 
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Figure  2.1. 2.1-3.  Remote  communicatioiK. 


Just  as  the  timesharing  user  communicates  with  the  system  by  way  of  his  terminal,  the 
batch  user  normally  communicates  by  way  of  the  card  reader.  (However,  he  can  also  enter 
his  job  from  an  interactive  terminal.)  Unlike  the  timesharing  user,  the  batch  user  can  punch 
his  job  on  cards,  insert  a few  appropriate  control  cards,  and  leave  the  job  for  an  operator  to 
run.  In  addition,  the  user  can  debug  the  program  in  the  timesharing  environment  and  then 
run  it  in  batch  mode  without  any  additonal  coding. 


The  GALAXY-10  system  consists  of  a series  of  programs:  QUASAR,  the  system  queue 
manager  and  scheduler;  SPRINT,  the  input  spooler;  BATCON,  the  batch  controller;  and  the 
output  spoolers,  LPTSPL  and  SPROUT.  The  input  spooler  is  responsible  for  reading  the 
input  from  the  input  device  and  for  entering  the  job  into  the  batch  controller’s  input . aeue. 
After  the  input  spooler  reads  the  end-of-file  and  closes  the  disk  iRles,  it  makes  an  entry  in 
the  batch  controller’s  input  queue.  The  batch  controller  processes  batch  jobs  by  reading  the 
entries  in  its  queue.  The  control  file  created  by  the  input  spooler  is  read  by  the  batch 
controller,  and  data  and  nonresident  software  commands  are  passed  directly  to  the  user’s 
job. 


QUASAR  is  responsible  for  scheduling  jobs  and  maintaining  both  the  batch  controller’s 
input  queue  and  the  output  spooling  queues.  A job  is  scheduled  to  run  under  the  batch 
controller  according  to  external  priorities,  processing  time  limits,  and  core  requirements 
which  are  dynamically  computed,  and  according  to  parameters  specified  by  the  user  for  his 
job,  such  as  start  and  deadline  time  limits  for  program  execution. 


The  output  spooling  programs  improve  system  throughput  by  allowing  the  output  from 
a job  to  be  written  temporarily  on  the  disk  for  later  transfer,  instead  of  being  written 
immediately  on  a particular  output  device.  The  log  file  and  all  job  output  are  placed  into 
one  or  more  output  queues  to  await  processing.  When  the  specified  device  is  available,  the 
output  is  then  processed  by  the  appropriate  spooling  program.  These  spooling  programs  may 
be  utilized  by  all  users  of  the  computing  system. 


2. 1.2.2  Program  Support  Software 


The  preparation  of  software  programs  in  both  assembly  language  and  in  several  higher 
order  languages  is  facilitated  by  the  various  utility  programs  and  compilers  supported  on  the 
AVSAIL  DEC-10.  The  basic  features  of  each  of  these  support  programs  are  briefly 
summarized  below. 
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i 2.1.2.2.1  Higher  order  language  compilers 

j 

\ A wide  range  of  higher  order  language  capability  is  supported  by  the  DEC-10  AVSAIL 

facility.  Languages  available  include  JOVIAL,  FORTRAN,  APL,  Basic,  COBOL,  and  others 
\ ns  subsequently  described.  The  descriptions,  other  than  for  JOVIAL,  are  brief  since  these 

' languages  are  widely  used  and  documented. 

2.1. 2.2.1. 1 JOVIAL.  The  JOVIAL  language  is  the  Air  Force  standard  language  for 
command  and  control  software,  and  the  level  I subset  of  J73  is  supported  with  a compiler 
on  the  DEC-10. 

I JOVIAL  had  its  beginnings  in  1958  and,  as  the  acronym  (Jule’s  Own  Version  of  the 

j International  Algebraic  Language)  implies,  is  similar  to  ALGOL  in  many  ways.  Subsequent 

modifications  over  the  years  have  left  it  substantially  different,  however.  The  introduction 
of  JOVIAL  brought  with  it  a number  of  innovative  software  features.  It  was  the  first 
j language  (and  until  PLA,  the  only  one)  to  provide  good  facilities  for  simultaneously 

>.  performing  scientific  numerical  computation  and  nontrivial  data  handling,  while  at  the  same 

time  it  could  also  be  used  in  general  information  handling  areas.  A second  contribution  is 
the  use  of  COMPOOL  (COMmunication  POOL)  as  a central  source  of  data  description.  A 
third  contribution  was  its  practical  usage  as  its  own  compiler,  and  finally,  it  made  a 
significant  contribution  in  terms  of  allowing  the  programmer  great  flexibility  for  controlling 
storage  allocation  when  he  needs  to,  but  not  requiring  him  to  do  so  otherwise.  It  is  not 
within  the  scope  of  this  manual  to  define  the  JOVIAL  language.  Readers  familiar  with 
FORTRAN  and  ALGOL  will  find  many  similarities.  A few  distinctive  features  of  JOVIAL 
' are  mentioned  here  to  differentiate  it  from  other  higher  order  languages. 

^ JOVIAL  is  a procedure-oriented,  problem-oriented,  and  problem-defining  language.  Its 

basic  objective  is  to  provide  a language  for  use  in  solving  large,  complex  information 
processing  problems.  Possibly  the  most  distinctive  feature  of  JOVIAL  related  to  this  basic- 
objective  is  the  COMPOOL.  The  COMPOOL  is  a facility  which  allows  for  creation  of  one  or 
more  preprocessed  common  data  base  descriptions.  The  COMPOOL  source,  as  defined  by  a 
COMPOOL  directive  and  declarations,  contains  two  types  of  information.  First,  data  declar- 
ations which  are  common  to  two  or  more  programs  may  be  described  in  a COMPOOL.  In 
addition,  any  external  procedures  or  functions  may  be  declared  in  the  COMPOOL.  The 
COMPOOL  process  involves  essentially  a compilation  of  the  COMPOOL  source,  creating  two 
forms  of  output.  One  output  is  a relocatable  object  module  containing  space  reservation  for 
the  data  delcared  in  the  COMPOOL  and  any  presets  defined  for  this  COMPOOL  data.  The 
i second  output  is  a special  file  containing  names  declared  in  the  COMPOOL  and  their 
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attributes  for  use  by  the  compiler  during  subsequent  compilations  which  refer  to  the  names 
declared  in  the  COMPOOL. 
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Another  feature  of  J73/I  worthy  of  note  is  the  absence  of  input/output  statements. 
Communication  with  JOVIAL  programs  is  via  the  compool  data  base.  Directives  are 
available  for  accessing  auxiliary  source  files,  however. 

Certain  features  of  the  J73  data  declarations  are  of  interest.  J73  supports  three  basic 
data  structures:  items  (scalar  variables);  tables  of  one  to  seven  dimensions;  and  blocks. 
Scalar  items,  tables  and  blocks  may  be  grouped  in  blocks.  Data  may  be  allocated  to  one  of 
three  levels.  The  primary  and  most  permanent  data  is  reserve  data.  Only  those  values  that 
are  left  in  reserve  data  upon  exit  from  a procedure  are  guaranteed  at  re-entrance  to  that 
procedure.  Procedure  data  values  are  not  valid  after  exit  from  the  containing  procedure.  The 
final  level  of  data  is  based  data.  No  storage  is  allocated  for  based  data  by  the  compiler. 
Based  data  describe  a structuring  of  data,  a template,  which  may  be  relocated  dynamically. 
This  relocation  may  be  performed  by  declaring  a default  base— an  item  whose  value  is  to  be 
used  as  the  address— or  at  each  reference  by  using  a formula  whose  value  is  the  address.  The 
allocation  level  to  be  ascribed  to  data  is  indicated  by  an  allocation  specifier  in  the 
declaration.  J73  also  provides  for  packing  of  table  items  at  three  levels;  no  packing,  dense 
packing,  or  medium  packing.  The  level  of  packing  implies  the  extent  to  which  more  than 
one  item  is  stored  in  a computer  word. 

The  J73/I  subset  provides  two  types  of  statements;  statements  that  compute  values  and 
statements  that  control  program  flow.  Statements  may  be  named  or  not  and  may  be  either 
simple  or  compound  (delimited  by  BEGIN  - END).  Program  control  statements  include 
GOTO,  STOP,  RETURN,  IF-ELSE,  WHILE  and  a particularly  powerful  FOR-Loop 
construct  which  is,  roughly  FOR  (control  variable),  BY  (increment  phrase),  THEN 
(replacement  phrase),  and  WHILE  (terminator  phrase).  The  BY,  THEN,  WHILE  elements 
may  appear  in  any  order. 

The  J73  language  is  program  and  procedure-oriented  and  a procedure  call  statement  is 
included.  The  J73  compilation  may  be  a program  that  is  invoked  by  an  operating  system  or 
a procedure  called  from  a program  or  other  procedure.  Within  a compilation  (program  or 
procedure),  internal  procedure  declarations  may  be  nested  to  any  level.  Within  a program,  a 
stop  statement  is  used  to  terminate  a program  or  procedure  and  return  to  the  system.  A 
return  statement  may  not  be  used  within  a program  but  may  be  used  within  a procedure. 

Some  additional  insight  into  the  nature  of  JOVIAL  is  provided  by  the  following  brief 
discussion  of  the  J73/I  compiler  which  is  composed  of  a data  base,  a set  of  seven  logical 
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processing  phases,  and  an  executive  program  which  supports  input/output,  phase  loading, 
and  commonly  used  utility  functions.  Interphase  communication  is  via  the  global  data 
blocks,  tables,  and  files  that  comprise  the  compiler’s  data  base.  The  structure  of  the  J73/I 
compiler  is  presented  in  Figiue  2.1.2.2-1.  Descriptions  of  the  compiler  components  are 
provided  below. 

Tlie  Compiler  Executive  (ECEX)  is  a collective  name  for  those  procedures  which  remain 
resident  throughout  a compilation.  Resident  procedures  are  of  three  types: 

1.  Host  Computer  Operating  System  Interface  Routines  where  routines  are  coded  in 
assembly  language;  they  support  phase  loading  and  file  input/output  and  must  be 
completely  recoded  to  rehost  the  compiler; 

2.  A collection  of  conversion  and  data  manipulation  procedures,  and  compiler 
debugging  procedures  which  output  symbolic  dumps  of  compiler  files  and  tables;  the 
conversion  and  data  manipulation  procedures  are  coded  in  assembly  language,  and 
debugging  procedures  are  coded  in  J73/I; 

3.  A collection  of  symbol  table  service  procedures  which  search  and  create  symbol 
table  entries;  these  procedures  are  coded  in  J73/I. 

The  Control  Card  Interpreter  (CCI)  reads  and  processes  control  card  command 
statements  for  the  compilation.  Examples  of  options  selectable  by  a command  statement 
are:  target  computer  identity,  input  and  output  file  names,  and  listing  options.  CCI  is 
currently  coded  in  assembly  language. 

The  Compool  Input  Processor  (CIP)  is  called  after  control  card  interpretation  to  process 
compool  directives.  CIP  presets  the  symbol  table  with  entries  from  the  compool  files  named 
in  the  compool  directives.  The  process  consists  of  reading  a compool  file’s  directory, 
searching  for  specified  entities,  obtaining  the  specified  entities  from  the  body  of  the 
Compool  File,  and  constructing  the  appropriate  symbol  table  entries. 

CIP  is  coded  in  J73/I.  Except  for  certain  data  declarations,  it  is  host  computer 
independent.  CIP  and  other  target  independent  compiler  modules  access  a global  table 
(TRGPARM)  of  target  parameters,  such  as  bits  per  word,  bits  per  byte,  and  address  size,  in 
order  to  generate  target>specific  output. 

Syntax  analysis  is  performed  by  the  Analyzer  (ANZR).  ANZR  translates  dynamic 
statements  to  Polish  postfix  form  in  the  Intermediate  Language  (IL)  file,  translates 
declarative  statements  into  symbol  table  entries,  and  copies  constant  presets  and 
cross-reference  information  to  the  code  file.  ANZR  is  coded  in  J73/I. 
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The  Allocator  ( ALOCTR)  is  responsible  for  assigning  relative  storage  addresses  for  data 
declarations  recognized  by  ANZR  as  as  result  of  a procedure  or  compool  compilation. 
ALOCTR  is  coded  in  J73/I. 

There  is  one  Optimizer/Code  Generator  pair  for  each  compiler  target  machine.  An 
Optimizer/Code  Generator  pair  is  referred  to  as  COGN.  COGN  operates  in  a two-pass 
manner  within  a single  phase.  Optimization  is  performed  during  the  first  pass  where  the  IL  is 
translated  to  a modified  IL.  Code  generation  and  register  assignment  are  performed  during 
the  second  pass,  where  the  modified  IL  is  transformed  into  the  Code  File. 

The  Editor  (EDIT)  reads  the  Code  File  and  produces  the  relocatable  object  program  file. 
EDIT  also  optionally  generates  an  edited  object  code  listing  and  a cross-reference  listing. 
There  is  one  EDIT  phase  per  target  computer. 

The  Compool  Processor  (COP)  executes  only  in  a compool  build  compilation.  It 
executes  after  EDIT  and  transforms  the  symbol  table  contents  into  a Compool  File  for  laU'r 
inclusion  in  compilations  which  refer  to  compool-declared  entities. 

The  major  compiler  data  base  elements  include  the  Symbol  Table,  Compilation  Control 
Block,  Intermediate  Language  File  and  Code  File.  The  Symbol  Table  consists  of  a 
fixed-length  hash  table  and  a variable-length  set  of  entries  that  describe  the  structures  and 
constructs  that  are  derived  from  source  language  parsing  (e.g.,  source-program -declared 
tables,  blocks,  and  procedures)  and  that  are  produced  to  assist  the  compiling  process  (e.g.. 
compiler-generated  labels  and  items).  There  are  two  types  of  symbol  table  entries;  name 
entries  and  attribute  entries.  Some  attribute  entries  describe  source  program  entities  which 
have  names,  such  as  variables,  procedures,  and  labels.  Since  names  are  variable  in  length,  and 
since  more  than  one  entity  can  bear  the  same  name,  the  name  part  of  a symbol  table  entry  is 
maintained  separately  from  the  related  attribute  information  that  describes  the  entity. 

The  Compilation  Control  Block  (CCB)  is  a small  core-resident  block  of  data  used  for 
communication  between  the  compiler  executive  and  the  phases.  CCB  is  a collection  of  items 
such  as  symbol  table  chain  headers,  a bit  vector  describing  compilation  options,  and  the 
current  statement  number. 

The  Intermediate  Language  (IL)  File  represents  the  executable  statements  of  a y)rogram 
in  Polish  postfix  form.  It  is  produced  by  the  syntax  analyzer  phase,  and  is  read  by  the 
optimizer /code  generator  pha.se.  The  IL  was  designed  to  simplify  optimization  and  code 
generation.  It  has  the  following  characteristics: 
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1.  The  IL  is,  in  general,  language  and  machine  independent; 

2.  All  conversions  are  explicitly  expressed  in  the  IL; 

3.  The  IL  is,  in  general,  nonredundant;  for  example,  a FOR  statement  is  expressed  in 


terms  of  simpler  statements  such  as  assignment,  IF,  and  GOTO. 

The  Code  File  (CF)  is  used  for  three  purposes:  (1)  it  contains  name  set/use  information 
produced  by  ANZR  for  the  cross-reference  listing;  (2)  it  contains  variable  preset  values 
produced  by  ANZR;  (3)  it  contains  the  tai^et  machine  instructions  produced  by  the  Code 
Generator.  The  Code  File  is  read  by  the  Editor. 

2. 1.2.2. 1.2  FORTRAN.  The  FORmula  TRANslator  language,  FORTRAN,  is  a widely 

, used  procedure-oriented  programming  language.  It  is  designed  for  solving  scientific-type 

problems  and  is  thus  composed  of  mathematical-like  statements  constructed  in  accordance 
with  precisely  formulated  rules.  Therefore,  programs  written  in  the  FORTRAN  language 
consist  of  meaningful  sequences  of  these  statements  that  are  intended  to  direct  the 
{ computer  to  perform  the  specified  computations.  DEC-10  FORTRAN-10  is  compatible  with 

I and  encompasses  an  ANSI  standard.  FORTRAN-10  also  provides  many  extensions  and 

j additions  to  this  standard  which  greatly  enhance  its  usefulness  and  increase  its  compatibility 

1 with  other  FORTRAN  language  sets.  Extensions  include  subroutines  which  allow  the 

i FORTRAN  user  to  do  real-time  programming.  With  these  subroutines,  the  time-sharing  job 

j can  dynamically  connect  real-time  devices  to  the  priority  interrupt  (PI)  system,  respond  to 

these  devices  at  interrupt  level,  remove  the  devices  from  the  PI  system,  and  change  their  PI 
level.  Use  of  these  routines  requires  that  the  user  have  real-time  privileges  and  be  able  to 
lock  his  job  in  core. 

' FOROTS,  the  FORTRAN-10  object-time  system,  implements  all  program  data  file 

functions  and  provides  the  user  with  an  extensive  runtime  error  reporting  system.  An 
additional  feature  is  that  the  association  between  FORTRAN  logical  units  and  the  file 
' descriptions  to  which  they  refer  may  be  either  made  within  the  source  program  or  deferred 

until  runtime.  DEC-10  FORTRAN-10  also  supports  FORDDT,  an  interactive  program  that 
• is  used  as  an  aia  in  debugging  FORTRAN  programs. 

2.1.2.2.1.3  ALGOL.  The  ALGOrithmic  Language,  ALGOL,  is  a scientific  language 
designed  for  describing  computational  processes,  or  algorithms.  It  is  a problem-solving 
language  in  which  the  problem  is  expressed  as  complete  and  precise  statements  of  a 
procedure.  The  DEC- 10  ALGOL  system  is  based  on  ALGOL-60.  It  is  composed  of  the 
ALGOL  processor,  or  compiler,  and  the  ALGOL  object  time  system.  Any  errors  made  in 
writing  the  program  are  detected  by  the  compiler  and  passed  on  to  the  user. 
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TTie  ALGOL  object  time  system  provides  special  services,  including  the  input/output 
service,  for  the  compiled  ALGOL  program.  Part  of  the  object  time  system  is  the  ALGOL 
library,  a set  of  routines  that  the  user’s  program  can  call  in  order  to  perform  calculations. 
These  include  the  mathematical  functions  and  the  string  and  data  transmission  routines. 
These  routines  are  loaded  with  the  user’s  program  when  required:  the  user  need  only  make 
a call  to  them.  The  remainder  of  the  object  time  system  is  responsible  for  the  running  of  the 
program  and  providing  services  for  system  resources,  such  as  core  allocation  and 
management  and  assignment  of  peripheral  devices. 

2.1.2.2.1.4  APL.  A Ehrogramming  Language  (APL)  is  a concise  programming  language 
especially  suitable  for  dealing  with  numeric  and  character  array-structured  data.  APL  is  a 
completely  conversational  system  which  tends  to  increase  programmer  productivity  and 
expertise  by  allowing  the  user  to  interact  with  the  APL  system  and  his  running  programs. 
APL  is  rich  in  operators  that  facilitate  array  calculations.  This  higher-level  programming  is 
accomplished  by  suppressing  much  of  the  programming  detail  inside  single  APL  operators. 
One  operator  may  be  used  to  sort  a vector  of  values  in  ascending  order,  thereby  making 
“sort”  a primitive  operation  rather  than  a tedious  subroutine.  APL  is  intended  for  use  as  a 
general  data  processing  language  as  well  as  a mathematician’s  tool. 

2.1.2.2.1.5  BASIC.  The  Beginner’s  All-purpose  Symbolic  Instruction  Code,  BASIC,  is  a 
problem-solving  language  that  is  easy  to  learn  because  of  its  conversational  nature.  It  is 
particularly  suited  to  a time-sharing  environment  because  of  the  ease  of  interaction  between 
the  user  and  the  computer.  The  BASIC  language  can  be  thought  of  as  divided  into  two 
sections:  one  section  of  elementary  statements  that  the  user  must  know  in  order  to  write 
simple  programs,  and  a second  section  of  advanced  techniques  for  more  powerful  programs. 

The  BASIC  system  has  several  special  features  built  into  its  design: 

1.  BASIC  contains  its  own  editing  facilities.  Existing  programs  and  data  files  can  be 
modified  directly  with  BASIC  instead  of  with  a system  editor  by  adding  or  deleting 
lines,  by  resequencing  the  line  numbers,  or  by  combining  two  files  into  one.  The 
user  can  request  a listing  of  all  or  part  of  any  of  his  files  on  either  the  line  printer  or 
the  terminal. 

2.  At  the  editing  level,  BASIC  allows  various  peripheral  devices  to  be  used  for  storage 
or  retrieval  or  programs  and  data  files;  within  a program,  information  can  be  read 
from  or  written  to  the  terminal  and  to  the  disk  (in  the  latter  case,  either  sequentially 
or  by  random  access); 

3.  Output  to  the  terminal  can  be  simply  formatted  by  tabs,  spaces,  and  column 
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headings  (W  more  precisely  formatted  by  using  the  advanced  PRINT  USING 
statement; 

4.  BASIC  has  statements  designed  exclusively  for  matrix  computations; 

5.  An  advanced  string  handling  capability  includes  a concatenation  operator,  substring 
and  search  functions,  and  other  string  intrinsic  functions;  mathematical  intrinsic 
functions  are  contained  in  BASIC,  along  with  methods  by  which  the  user  can  define 
his  own  functions. 

2.1.2.2.1.6  AID.  The  Algebraic  Interpretive  Dialogue,  AID,  is  the  DEC-10  adaption  of 
the  language  elements  of  JOSS,  a program  developed  by  the  RAND  Corporation.  To  write  a 
program  in  the  AID  language  requires  no  previous  programming  experience.  Commands  to 
AID  are  typed  in  via  the  user’s  terminal  as  imperative  English  sentences.  Each  command 
occupies  one  line  and  can  be  executed  immediately  or  stored  as  part  of  a routine  for  later 
execution.  The  beginning  of  each  command  is  a verb  taken  from  the  set  of  AID  verbs.  These 
verbs  allow  the  user  to  read,  store,  and  delete  items  in  storage;  halt  the  current  processing 
and  either  resume  or  cancel  execution;  type  information  on  his  terminal;  and  define 
arithmetic  formulas  and  functions  for  repetitive  use  that  are  not  provided  for  in  the 
language.  However,  many  common  algebraic  and  geometric  functions  are  provided  for  the 
user’s  convenience. 

The  AID  program  is  device-independent.  The  user  can  create  external  files  for  storage  of 
subroutines  and  data  for  subsequent  recall  and  use.  These  files  may  be  stored  on  any 
retrievable  storage  media,  but  for  accessibility  and  speed,  most  files  are  stored  on  disk. 

2.1.2.2.1.7  COBOL.  The  COmmon  Business  Oriented  Language,  COBOL,  is  an 
industrywide  data  processing  language  that  is  designed  for  business  applications,  such  as 
payroll,  inventory  control,  and  accounts  receivable. 

Because  COBOL  programs  are  written  in  terms  that  are  familiar  to  the  business  user,  he 
can  easily  describe  the  formats  of  his  data  and  the  actions  to  be  performed  on  this  data  in 
simple  English-like  statements.  Therefore,  programming  training  is  minimal.  COBOL 
programs  are  self-documenting,  and  programming  of  desired  applications  is  accomplished 
quickly  and  easily. 

DEC-10  COBOL  accepts  two  source  program  formats:  conventional  format  and 
standard  format.  The  conventional  format  is  employed  when  the  user  desires  his  source 
programs  to  be  compatible  with  other  COBOL  compilers.  This  is  the  format  normally  used 
when  input  is  from  the  card  reader.  The  standard  format  is  provided  for  users  who  are 
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familiar  with  the  format  used  in  DEC-IO  operations.  It  differs  from  conventional  format  in 
that  sequence  numbt*rs  and  identification  an*  not  u.scd  because  most  DEC- 10  prop'ams 
require  neither. 

2.1.2.2.1.8  DBMS.  The  Data  Base  Management  SysU*m  (DBMS-10)  is  a facility  of  the 
DEC-10  that  j)ermits  the  user  to  consolidate  his  data  files  into  one  or  more  data  biises.  A 
data  base  is  a collection  of  nonredundant  data  items  that  can  be  accessed  by  a variety  of 
programs  and/or  applications  that  have  common  processing  requirements  and  functional 
relationships.  The  data  bast*  is  created  and  maintained  through  modules  of  DBMS-10.  The.se 
modules  permit  the  user  to  structure  the  data  in  such  a way  that  each  application  can  access 
in  an  optimum  fashion,  yet  no  data  item  is  actually  duplicated  in  the  data  base.  This 
arrangement  is  accomplished  by  the  data  administrator  who  structures  the  data  base  in  a 
manner  such  that  each  application  can  access  it  through  a search  pattern  most  suited  to  its 
needs.  Once  the  data  base  has  been  established,  users  can  access  the  data  through  COBOL 
programs  containing  special  data  base  syntox. 

2.1 .2.2.2  Utility  software 

2.1.2.2.2.1  MACRO  Assembler.  MACRO  is  the  symbolic  a.ssembly  program  on  Uie 
DEC-10.  It  generat€*s  machine  language  programs  by  performing  the  following  functions: 

1.  Translating  symbolic  operation  codes  in  tlie  source  program  into  the  binary  code.s 
needed  in  machine  language  instructions; 

2.  Relating  symbols  specified  by  the  u.s»'r  to  numeric  values; 

3.  A.s.signing  absolute  core  addre.sses  to  the  symbolic  addresses  of  program  in.structions 
and  data; 

•1.  Preparing  an  output  listing  (»f  the  program  which  includes  any  errors  iletected 
during  the  assembly  process. 

MACRO  is  a two-pass  assembler.  This  means  that  the  a.ssembler  reads  the  souree 
program  twice.  Basically,  on  the  first  pass,  all  symbols  are  ilefined  and  placed  in  the  symbol 
table  with  their  numeric  values,  and  on  the  second  pass,  tlie  binar>’  (machine)  code  is 
generatt'd.  Although  not  as  fast  as  one-pass  assembler,  MACRO  is  more*  efficient  in  that  le.ss 
core  is  used  in  generating  the  machine  language  code  and  the  output  to  the  user  is  not  as 
long. 

MACRO  is  a device-independent  program;  it  allows  tlie  user  to  .select,  at  runtime, 
standard  peripheral  devices  for  input  and  output  files.  For  example,  input  of  the  souree 
program  can  come  from  the  user’s  terminal  and  output  of  the  assembled  binar>’  program  can 
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go  to  a magnetic  tape,  and  output  of  the  program  listing  can  go  to  the  line  printer.  More 
commonly,  the  source  program  input  and  the  binary  output  are  disk  files. 


2. 1.2. 2. 2. 2 Linking  Loader.  LINK-10,  tire  DEC  10  linking  loader,  merges 
independently  translated  modules  of  the  ust‘r’s  program  into  a single  module  and  links  this 
module  with  system  mcxlules  into  a form  that  can  be  executed  by  the  operating  system.  It 
provitles  automatii-  relocation  and  loading  of  the  binary  modules  producing  an  executable 
version  of  the  iKser’s  program.  When  the  loading  process  has  been  completed,  the  user  can 
request  LINK- 10  either  to  transfer  control  to  his  program  for  immediate  execution  or  to 


output  the  program  to  a device  for  storage  in  order  to  avoid  the  loading  procedure  in  the 
future. 

While  the  primary  output  of  LINK-10  is  the  executable  version  of  the  user’s  program, 
the  user  can  request  auxiliary  output  in  the  form  of  map,  log,  save,  symbol,  overlay  plot, 
and  expanded  core  image  files.  This  additional  output  is  not  automatically  generated;  the 
user  must  include  appropriate  switches  in  his  command  strings  to  LlNK-10  in  order  to 
obtain  this  type  of  output.  The  user  can  also  gain  precise  control  over  the  loading  process  by 
setting  various  loading  parameters  and  by  controlling  the  loading  of  symbols  and  modules. 
Furthermore,  by  setting  switches  in  his  command  strings  to  LINK-10,  the  user  can  specify 
the  core  sizes  and  starting  addresses  of  modules,  the  size  of  the  symbol  table,  the  segment 
into  which  the  table  is  placed,  the  messages  he  will  see  on  his  terminal  or  in  his  log  file,  and 
the  severity  and  verbosity  levels  of  Uie  messages.  Finally,  he  can  accept  the  LINK-10 
defaults  for  items  in  a file  specification  or  he  can  set  his  own  defaults  that  will  be  used 
automatically  when  he  omits  an  item  from  his  command  string.  LINK-10  has  an  overlay 
facility  to  be  used  when  the  total  core  required  by  a user’s  program  is  more  than  the  core 
available  to  the  user. 

2.1.2.2.2.3  Program  Debugging.  The  Dynamic  Debugging  Technique,  DDT,  is  used  for 
on-line  program  composition  of  object  programs  and  for  on-line  checkout  and  testing  of 
these  programs.  F'or  example,  the  user  can  perform  rapid  checkout  of  a new  program  by 
making  a change  resulting  from  an  error  detected  by  DDT  and  then  immediately  executing 
that  section  of  the  program  for  testing. 

After  the  source  program  has  been  compiled  or  as.sembled,  the  binary  object  with  its 
table  of  defined  symbols  is  loaded  with  DDT.  In  command  strings  to  DDT,  the  user  cim 
specify  locations  in  his  program,  or  breakpoints,  where  DDT  is  to  suspend  execution  in 
order  to  accept  further  commands.  In  this  way,  tlie  user  can  check  out  his  program 
section-by -section  and  if  an  error  occurs,  the  ust>r  can  insert  the  corrected  code  immediately. 
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> 2.1.2.2.2.4  File  Manipulation.  The  Peripheral  Interchange  Program,  PIP,  is  used  to 

I transfer  data  files  from  one  I/O  device  to  another.  Commands  to  PIP  are  formatted  to 

I accept  any  number  of  input  (source)  devices  and  one  output  (destination)  device.  Files  can 

^ be  transferred  from  one  or  more  source  devices  to  the  destination  device  as  either  one 

i combined  file  or  individual  files.  Switches  contained  in  the  command  string  to  PIP  provide 

the  user  with  the  following  capabilities: 

( 

I : 1.  Naming  the  files  to  be  transferred, 

f ' 2.  Editing  data  in  any  of  the  input  files, 

I 3.  Defining  the  mode  of  transfer, 

j 4.  Manipulating  the  directory  of  a device  if  it  has  a directory, 

I 5.  Controlling  magnetic  tape  and  card  punch  functions, 

I 6.  Recovering  from  errors  during  processing. 

i 

! 2.1.2.2.2.5  File  Editing.  The  Text  Editor  and  Corrector  program,  TECO,  is  a powerful 

editor  used  to  edit  any  ASCII  text  file  with  a minimum  of  effort.  TECO  commands  can  be 
separated  into  two  groups:  one  group  of  elementary  commands  that  can  be  applied  to  most 
editing  tasks,  and  the  larger  set  of  sophisticated  commands  for  character  string  searching, 
text  block  movement,  conditional  command,  programmed  editing,  and  command  repetition. 

TECO  is  a character-oriented  editor.  This  means  that  one  or  more  characters  in  a line 
can  be  changed  without  retyping  the  remainder  of  the  line.  TECO  has  the  capability  to  edit 
any  source  document:  programs  written  in  MACRO,  FORTRAN,  COBOL,  ALGOL,  or  any 
other  source  language;  specifications;  memorandums,  and  other  types  of  arbitrarily 
formatted  text.  The  TECO  program  does  not  require  that  line  numbers  or  other  special 
formatting  be  associated  with  the  text.  Editing  is  performed  by  TECO  via  an  editing  buffer, 
which  is  a section  within  TECO’s  core  area.  Editing  is  accomplished  by  reading  text  from 
any  device  into  the  editing  buffer  (inputting),  by  modifying  the  text  in  the  buffer  with  data 
received  from  either  the  user’s  terminal  or  some  other  device  (insevting),  and  by  writing  the 
modified  test  in  the  buffer  to  an  output  file  (outputting). 

I 2.'l.2.2.2.6  Manuscript  Editing.  RUNOFF  facilitates  the  preparation  of  typed  or 

printetl  manuscripts  by  jx'rforming  line  justification,  page  numl>ering.  titling,  indexing, 
formatting,  and  case  shifting  ns  directed  by  the  user.  The  user  creates  a file  with  an  inlitor 
and  enters  his  material  through  his  U’rminal.  In  addition  to  entering  the  text,  the  user 
includes  information  for  formatting  and  case  shifting.  RUNOFF'  processes  the  file  and 
produces  the  final  formatted  file  to  Ih>  output  to  the  terminal,  the  line  printer,  or  to  another 
file. 
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With  RUNOFF,  large  amounts  of  material  can  be  inserted  into  or  deleted  from  the  file 
without  retyping  the  text  that  will  remain  unchanged.  After  the  group  of  modifications  have 
been  added  to  the  file,  RUNOFF  produces  a new  copy  of  the  file  which  is  projierly  (laged 
and  formatted. 

2.1.3  Special  Purpose  Peripherals 

In  order  to  provide  the  capability  for  simulations  which  assess  the  influence  of  human 
■ factors  on  avionic  system  performance,  the  AVSAIL  laboratory  includes  a simulated  cockpit 

and  computer-generated  visual  displays  of  the  external  environment  and  the  cockpit  flight 
data  displays.  The  functional  configuration  of  these  elements  of  AVSAIL  is  shown  in  Figurt* 
2.1.3-1.  The  elements  shown  are  configured  in  three  basic  subsystems,  which  an'  referred  to 
here  as  (1)  the  Picture  System,  (2)  the  Video  System,  and  (3)  the  Cockpit  Simulator.  Overall 
communication  between  these  special  purpose  peripherals  is  through  the  DEC-10  which 
executes  the  simulation  models.  Capabilities  of  each  of  these  three  peripheral  sulisystems  are 
j described  in  succeeding  sections. 

I 

< 2.1.3.1  Th«  Picture  System 

I 

i The  Picture  System  is  a standalone  general  purpost',  interactive  computer  graphics 

t system  which  can  display  smoothly  moving  pictures  of  two-  or  three-<Iimen8ional  objects 

! effectively  in  real  time.  The  basic  components  of  the  system,  manufactured  by  the  Evans  & 

Sutherland  Computer  Corporation,  are  a DEC  PDP-11;  hardware  processing  units  which 
perform  such  functions  as  rotations,  zooming,  and  perspective;  an  8172-vmint  Refresh 
Buffer;  a Picture  Generator;  a Character  Generator;  a 21  in.  Picture  Display;  a Tablet  to 
! facilitate  picture  interaction ; and  the  soft  wart'  to  support  the  system. 

Figure  2.1 .3.1-1  is  an  overall  view  of  the  Picture  System  interfaced  with  a DEC 
• PDP-11/50  computer.  A close-up  view  of  the  Input  Tablet,  and  21  in.  Picturt>  Display  (with 

a typical  display  configuration)  is  shown  in  Figure  2. 1.3. 1-2.  The  tablet  st'rves  as  the 
. standard,  general-purpose,  graphic  input  device  in  THE  PICTURE  SYSTEM.  The  tablet  can 

be  used  for  positioning  or  pointing  to  the  pictun'  elements  by  use  of  a pen  whost'  x and  y 
coordinates  are  read  by  the  picture  controller.  In  this  manner,  the  tablet  and  )H'n  can  Ih' 
I used  to  simulate  functions,  such  as  joy  .stick  control,  such  that  the  operator  I’an  interactively 

"fly  the  simulation."  An  operator  seated  at  the  Input  Tablet  is  shown  "flying  the 
.simulation"  in  Figure  2.1. 3.1-3. 


I 
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Figure  2.1. 3.1  2.  The  Picture  dtipljy  and  tablet 


2.1. 3.1.1  Overview  of  interactive  computer  graphics 

Intenu  livf  (.omputor  t^aphu  s allows  a user  to  liu  laU*  channi's  to  iht*  picturi'  ami  set*  tlu* 
resulus  immtxl lately.  The  system  time  lag  is  a very  small  fraction  of  a second,  and  the  user 
gets  the  feeling  that  he  is  actually  manipulating  the  pictim*  itself  in  real  time. 

('ompuU-r  graphics  is  a very  broad  suhjt'ct,  encomjiassing  many  iletails  which  are  not 
(HTtinent  here.  However,  some  appreciation  of  the  more  basic  aspi*cts.  as  represented  by  the 
.\VS.\IL  Ihcture  System,  will  help  to  orient  the  reader.  Four  topic  areas  an'  prest'ntwl  in 
sul>st>quent  sections:  prest'nting  a prepare  pictun*,  n*pn'senting  stnictures  to  In*  depicted, 
prepanng  a pictun*  of  such  stnictures,  and  inh'racting  with  the  pictun*. 

2. 1.3. 1.2  Picture  presentation 

2.1. 3.1. 2.1  Graphical  Output  Media.  Output  media  fall  into  two  basic  divisions, 
fiermanent  and  impermanent.  PlotU*rs  and  roster  printers  an*  e.vamples  of  the  first  tyfv, 
which  do  not  lend  themselves  to  interactive  applications.  The  cathode  ray  tulx*  (CRT)  is  the 
most  widely  used  impermanent,  interactive  display  device.  Information  is  pre.sented  on  a 
CRT  by  directing  a beam  of  electrons  about  on  its  phosphor  coated  fai*e.  The  CRT  fai*e 
emits  light  for  an  instant  when  it  is  struck  by  the  electron  bi*am  and  Uien  turns  dark.  For 
the  picture  to  be  visible  it  must  lx*  redrawn  or  refreshed  very  frequently.  The  n*fresh  CRT 
used  by  the  Picture  System  can  be  drawn  upon  with  a set  of  strokes  at  any  position  and  any 
angle. 

2. 1.3.1. 2. 2 Refresh  Rate.  Since  the  phosphor  on  the  refresh  CRT  fades  almost 
immediately  after  it  is  struck  by  the  electron  lH*am,  the  picture  must  lx*  continually  it'drawn 
to  lx*  viewed.  This  rate  at  which  it  is  redrawn  is  called  the  rt'fresh  rate,  usually  measurt'd  in 
frames  per  second.  If  the  picture  is  not  redrawn  frequently  enough,  the  eye  will  notice  it 
fading  between  refreshes,  (woducing  an  unsightly  effect  known  as  flicker.  To  avoid  flicker, 
the  Picture  System  is  refreshed  at  a rate  which  is  greater  than  thirty  times  pt'r  second. 

2.1. 3.1. 2.3  Line  Generation.  A line  is  specified  by  two  end-points  (x,y)  and  (x'.y'l, 
expressed  in  the  coordinate  system  of  the  CRT,  called  screen  coordinates.  The  actual 
movement  of  the  electron  beam  lx*tween  the  two  jxiints  is  accomplished  by  a hardwan* 
device  called  a line  generator  or  a vector  generator.  A sophisticated  line  generator  is  also 
capable  of  drawing  lines  with  a program-specified  irU*nsity.  or  even  varying  the  intensity  of 
a bne  from  one  end  to  the  other.  In  this  most  general  case,  where  line  endpoints  are 
specified  by  the  three  coordinates  (x,y,z).  the  intensity  or  brightness  of  lines  can  appear  to 


88 


trail  off  in  the  distance,  producing  an  illusion  of  depth.  This  technique  is  known  as 
depth-cueing. 

2.1.3.1.2.4  Update  Rate.  The  advantage  of  the  refresh  CRT  is  that  it  can  show 
smoothly  changing  pictures.  Lines  drawn  on  a CRT  do  not  really  move,  of  course,  but  the 
illusion  of  motion  is  imparted  by  continually  redrawing  the  picture  of  each  frame  with  lines 
at  slightly  different  positions  each  time.  The  eye  blends  this  sequence  of  slightly  different 
frames  together  into  a smoothly  moving  picture  such  as  a motion  picture.  The  rate  at  which 
these  different  frames  can  be  displayed  is  called  the  update  rate.  In  contrast  to  the  refresh 
rate  which  counts  the  number  of  pictures  drawn  per  second,  whether  or  not  they  are 
changed,  the  update  rate  counts  only  those  frames  that  are  different.  An  update  rate  of 
10-20  frames  per  second  will  provide  smooth  motion. 

2.1. 3.1. 2.5  Picture  Buffering.  In  the  Picture  System  a refresh  buffer  provides  storage  so 
that  the  refresh  and  update  rates  may  be  different.  Although  refresh  of  30-40  frames  per 
second  is  required  to  avoid  flicker,  update  of  10-20  frames  per  second  is  adequate  tc  provide 
smooth  motion.  In  effect,  each  new  frame  is  shown  two,  three,  or  even  four  times  while  the 
next  frame  is  being  computed. 

Data  resident  in  a refresh  buffer  is  called  a Display  File.  Full  frames  stored  in  this  buffer 
may  be  read  out  and  used  to  refresh  the  CRT  any  number  of  times  before  a new  frame  is 
created.  Typically,  new  frames  are  created  20  times  a second  and  the  picture  is  refreshed  40 
times  a second;  i.e.,  each  frame  is  shown  twice.  Thus,  the  presence  of  a refresh  buffer  allows 
both  refresh  and  update  to  proceed  at  their  respective  optimal  rates  and  the  system  has  a 
larger  line  capacity  than  it  otherwise  would. 

A potential  problem  area  exists  when  a picture  is  refreshed  from  a memory  which  is 
simultaneously  being  filled  with  a new  frame,  namely,  that  a picture  displayed  may  consist 
of  some  lines  from  one  frame  and  some  from  another.  This  can  produce  a number  of  effects, 
some  very  unsightly.  To  avoid  this  problem,  the  refresh  buffer  can  be  split  into  two  separate 
buffers,  and  update  and  refresh  can  be  switched  between  the  two  in  a way  which  avoids 
conflicts.  This  is  called  double-buffering,  and  its  only  disadvantage  is  that  the  amount  r<f 
pictorial  data  which  may  be  buffered  is  halved.  In  some  cases  this  can  place  an  unnecessarily 
low  ceiling  on  the  line  capacity.  The  alternative,  single  buffering,  can  be  used  to  take 
advantage  of  the  entire  buffering  space  when  the  effects  are  not  too  disturbing,  usually 
when  the  pictures  shown  are  not  highly  dynamic. 
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2.1.3.1.3  Picture  dafinition 

Data  ultimately  deposited  in  a refresh  buffer  must  originate  in  the  memory  of  the 
computer  controlling  the  system.  This  computer-resident  data  is  called  a Data  Base  and  may 
be  vastly  different  in  form  from  the  display  file  which  emanates  from  it. 

The  data  has**  contains  the  coordinates  of  points  in  the  structure  to  be  displayed,  along 
with  instructions  for  interpreting  Uiose  points.  Along  with  coordinate  information  there 
may  be  pointers,  substructure  names,  and  other  non-graphic  information  and  attributes. 

Points  are  the  basic  geometric  entities  in  the  data  base.  There  are  three  basic  instructions 
for  treating  a point,  move  the  beam  to  that  (xiint,  draw  a line  to  that  point,  or  draw  a dol 
at  that  (>oint. 

The  most  straightforward  way  to  specify  the  position  of  a point  is  simply  to  state  its 
absolute  coonlinates.  An  alternative  that  often  introduces  considerable  efficiencies,  called 
relative  coordinates,  entails  stating  the  displacement  required  to  get  to  a point  from  the 
previous  point.  Codes  for  common  sequences  like  "absolute,  relative,  absolute,  relative.  . . .” 
can  be  made  recognizable  to  facilitate  handling  tables  of  points. 

If  a structutt'  to  be  displayed  lies  in  a plane,  it  is  simplest  and  most  efficient  to  define  it 
using  two-dimensional  data.  In  this  case  it  is  typical  to  supply  an  x and  a y coonlinate  for 
each  point  in  the  structure,  and  then  perhaps  a single  z coonlinate  which  applies  to  all  the 
points. 


If  however,  the  structun'  is  non-plauar.  it  must  be  defined  ns  thn*e-dimensional  data 
where  a coordinate  triple  of  the  form  (x.y.z)  is  given  for  each  point. 

In  general  a full  computer  word  is  devoted  to  each  coonlinaU'  of  each  point  and  all 
coordinates  are  expressed  as  inU*gers.  In  the  Id-bit  computer,  then,  the  largest  expn'ssihle 
positive  number  is  ;i'27fi7.  This  is  sufficient  for  many  applications,  but  the  need  to  express 
larger  numbers  sometimes  arises.  This  need  can  be  met,  at  the  exjx'p.se  of  some  loss  »>f 
resolution  in  data  definition,  by  employing  an  alternate  means  of  expressing  data  called 
homogeneous  coordinates.  Here  a point  (x,y,z)  is  defined  by  the  four  coonlinates 
(hx,hy,hz,h- , '127(57),  svhere  h is  an  arbitrary  number  between  zero  and  one.  It  is  aptiarent 
though  that  resolution  is  lost;  whim  h is  1/2,  it  is  impo.ssible  to  exactly  express  odd  values 
for  the  original  coordinates.  Smaller  values  of  h impose  a correspondingly  greater  loss  ot 
resolution. 
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It  is  customary  to  conserve  core  by  supplying  only  the  first  three  coordinates  (hx.hy.hz) 
for  three-dimensional  points,  or  just  two  coordinates  (hx,hy)  for  two-dimensional  points 
(with  a common  value  for  hz),  and  to  prespecify  a fourth  coordinate  (usually  referred  to  as 
w)  which  applies  to  several  such  points. 

2. 1.3. 1.4  Picture  preparation 

The  data  base  is  almost  never  identical  to  the  display  file  because  the  base  represents 
some  view  of  that  scene.  To  create  a display  file,  transformation  of  the  data  base  is  required. 
In  order  to  prepare  a structure  for  display,  it  may  have  to  be  changed  in  size,  position,  or 
orientation;  it  may  have  to  be  put  in  perspective  as  seen  from  a given  vantage  point;  parts  of 
it  may  have  to  be  removed  to  keep  everything  within  a given  field  of  view;  and  its 
coordinate  system  may  have  to  be  changed  to  conform  with  the  output  device.  All  of  these 
steps  can  be  expressed  mathematically  and  implemented  in  software  or  hardware. 

Fortunately,  since  many  of  the  steps  involved  in  picture  preparation  are  invariant  from 
application  to  application,  it  is  very  worthwhile  to  implement  them  with  special  purpose 
hardware.  Any  calculations  unique  to  a given  application  can  still  be  performed  in  software. 
To  meet  the  demand  for  fast  frame  creation,  high  performance  graphic  systems  employ 
special  purpose  hardware  processors  to  implement  the  picture  preparation  steps.  These  steps 
are  described  in  the  following  sections. 

2. 1.3. 1.4.1  Simple  Linear  Transformations.  Linear  transformations  (rotations, 
translations,  scalings,  etc.)  can  be  described  by  parameters  which  indicate  the  type  and 
degree  of  information.  If  the  transformation  parameters  are  properly  arranged  into  a matrix, 
a vector  of  original  coordinates  can  be  multiplied  by  this  matrix  to  yield  a vector  of  new 
coordinates  reflecting  the  desired  transformation. 

A 4 X 4 matrix  can  represent  any  rotation,  translation,  or  change  in  scale  and  can  be 
used  to  transform  points  represented  by  homogeneous  coordinates  or,  as  special  cases, 
two-dimensional  or  three-dimensional  coordinates. 

2. 1.3. 1.4.2  Compound  Linear  Transformations.  All  linear  transformations  can  be 
expressed  as  a sequence  of  simple  translations,  rotations,  and  changes  in  scale.  A 
transformation  expressible  only  by  such  a sequence  is  called  a compound  transformation. 
When  a compound  transformation  is  to  be  applied  to  a set  of  points,  first  a composite 
matrix  is  formed  by  multiplying  together  matrices  representing  all  the  simple 
transformations  in  the  sequence,  in  the  same  order  in  which  the  data  would  have 
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tMu-ountered  the  original  transformations,  and  thon  applyinn  this  composite  matrix  to  all 
points  to  be  transformed.  The  process  is  known  as  transformation  concaUmation. 

2.1.3.1.4.3  Perspective.  The  perspective  operation  entails  computing  a point  projection 
of  three-dimensional  points  onto  a plane  representative  of  the  screen,  as  depicted  in  Figure 
2.1. 3. 1-1.  I’ersiKH'tive  can  be  applied  to  thrt'e-dimensional  data  by  taking  advantage  of  the 
fact  that  the  persjx'ctive  transformation  is  expressible  in  matrix  form:  a perspective 
transformation  matrix  can  be  included  at  the  end  of  the  sequence  of  rotation,  translation, 
and  scale  matnces  to  tiansform  three-dimensional  data  into  a two-dimensional  perspective 
representation. 

2. 1.3. 1.4.4  Windowing.  In  some  graphics  applications,  the  data  bast*  is  displayed  in  its 
entirety  on  tlie  screen.  Often,  however,  a closeup  of  some  portion  of  the  data  base  is  desired 
and  the  rest  is  preferably  omitted.  Determining  what  to  omit  is  so  time-consuming  in 
software  that  it  jeopardizes  the  dynamic  movement  of  the  pictun*. 

The  Picture  System  can  address  this  so-called  windowing  problem  by  performing  a 
visibility  check  in  hardware  after  the  transformation  stage  and  drawing  only  visible  lines  on 
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the  display.  One  implementation  of  windowing  is  called  clipping,  and  entails  comparing  all 
lines  with  the  boundaries  of  a program-specified  field  of  view  superimposed  on  the  data 
base.  Lines  or  portions  of  lines  outside  the  field  of  view  are  eliminated  and  only  visible  lines 
are  passed  on  for  display  on  the  screen. 

In  two  dimensions,  the  field  of  view  is  a rectangle  called  a window,  superimposed  on  the 
plane  of  the  data  base.  Clipping  is  easiest  if  the  sides  of  the  rectangle  are  parallel  with  the 
coordinate  axes;  however,  this  presents  no  restriction  since  the  effect  of  a rotated  window 
can  be  obtained  by  rotating  the  data  in  the  opposite  direction. 

A window  is  specified  by  supplying  values  for  its  left,  right,  bottom,  and  top  boundaries 
using  the  same  coordinate  system  used  in  the  data  base.  Two-dimensional  clipping  is 
diagrammed  in  Figure  2. 1.3. 1-6. 


WINDOW 
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BOTTOM 


WINDOW  WINDOW 

LEFT  RIGHT 


LINE  LEFT  INTACT  BY  THE 
CLIPPING  PROCESS 


LINE  SEGMENT  REMAINING 
AFTER  CLIPPING  PROCESS 


LINE  SEGMENTS  REMOVED 
BY  THE  CLIPPING  PROCESS 


LINE  ENTIRELY  REMOVED  BY 
THE  CLIPPING  PROCESS 


Figure  Z1.3.t-S.  Tvra  dimtntional  clipping. 
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In  three  dimensions  the  field  of  view  is  a three-dimensional  region.  It  may  be  a 
recUngular  volume,  or,  if  its  contents  are  to  be  seen  in  perspective,  a section  of  a pyramid 
csdled  a frustum  of  vision.  Such  a frustum  is  shown  in  Figure  2. 1.3. 1-6  along  with  the 
parameters  necessary  to  completely  specify  it. 


RIOHT  \ 


Fi|ura  2.1.11-6.  Frustum  of  vision  showing  tho  tyt  position  in  roiotion  to  in  irbitrarv  coordintt*  skis. 


In  Figure  2.1. 3.1-6  an  eye  positioned  at  point  K along  the  '/  axis  is  to  st*e  the  portion  of 
the  data  base  that  lies  within  the  frustum  whost'  hither  (near)  boundary  is  at  point  H.  yon 
(far)  boundary  is  at  point  Y,  and  whose  side  boundaries  are  determined,  as  in  tlu* 
two-dimensional  case,  by  the  window  left,  right,  bottom,  and  top  boundaries  at  the  hither 
plane. 

As  in  the  two-dimensional  case,  lines  are  retained,  completely  eliminated,  or  partially 
eliminated,  depending  on  whether  they  are  completely  within,  completely  outside,  or 
partially  outside  the  frustum  of  vision. 

Another  approach  to  windowing  is  called  scissoring.  Scissoring  entails  making  available  a 
screen  coordinate  drawing  space  which  is  somewhat  larger  than  the  screen  itself  and  then 
intensifying  only  the  lines  and  line  segments  actually  on  the  screen.  Scissoring  is  easier  to 
implement  than  clipping  and  does  not  take  up  time  in  the  picture  preparation  stage.  On  the 
other  hand,  scissoring  permits  an  effective  drawing  ari'a  only  slightly  larger  than  the  screen 
as  opposed  to  the  vastly  larger  effective  drawing  art'a  permitted  by  clipping.  Another 
disadvantage  of  scissoring  is  that  the  line  generator  spends  time  tracing  out  all  lines,  both 
visible  and  invisible,  which  makes  flicker  occur  more  readily. 

2.1.3.1.4.5  Conversion  to  Screen  Coordinates.  Coontinate  data  tirat  is  not  rejecUnl  by 
the  clipping  process  is  within  limits  determined  by  the  field  of  view  which  may  1h'  of  any 
size  and  at  any  position  in  the  data  base  definition  space.  However,  it  is  generally 
undesirable  to  display  that  data  in  a corresponding  size  and  position  on  the  screen.  Ratlrer, 
the  data  should  be  properly  scaled  (or  mapped)  so  that  it  fills  some  program-spet'ified  region 
on  the  screen  called  a viewport.  This  can  be  accomplished  by  performing  a final  processing 
step  which  linearly  maps  all  data  from  the  window  to  the  viewport. 

If  the  viewport  is  a rectangular  region  aligned  with  the  screen  axes,  it  can  Ik>  specified  by 
supplying  the  screen  coordinates  for  its  left,  right,  bottom,  and  top  edges.  If  the  sysU'm’s 
line  generator  can  draw  lines  of  varying  intensity,  a viewport  may  also  specify  the  intensity 
limits  for  the  data  displayed.  Thest'  limits  specify  the  intensities  of  tlie  data  at  the  hither  and 
yon  boundaries  and  are  called  the  hither  and  yon  inUmsities.  When  the  hither  and  yon 
intensities  are  different,  the  intensity  of  the  displayed  picturt>  elements  varies  betwerm  these 
limits,  allowing  an  illusion  of  depth  to  be  imparted  to  the  picture.  A viewport  is  used  to 
specify  the  region  of  screen  and  the  intensity  limits  for  the  data  to  which,  in  the  most 
general  case,  the  frustum  of  vision  is  mapped.  Figur»*s  2. 1.3. 1-7  and  S .show  how  data  may 
be  displayed  witliin  a viewport  which  is  the  entire  .screen  or  only  a piirtion  of  it.  Viewports 
may  also  he  utilizt'd  to  map  data  into  the  coordinates  of  devices  other  than  a ilisplay.  For 
example,  viewport  boundaries  could  be  specified  in  the  coortlinate  system  of  a plotter  or 
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limilar  device  to  provide  the  capability  of  obtaining  hard  copy  output  to  the  precision  of 
the  plotting  devii'e. 

An  advantage  of  program-specified  viewports  is  that  several  may  be  assigned  in  the  same 
program,  each  receiving  different  data.  This  technique  proves  convenient  for  many  purposes 
in  graphics,  such  as  showing  different  views  of  an  object  or  views  in  different  directions 
from  the  same  point  on  the  same  output  device  simultaneously. 

2.1.3.1.4.6  Text  Display.  Almost  all  graphics  applications  call  for  the  presentation  of 
alphanumerics  on  the  scr»‘en  at  one  time  or  another.  It  is  possible  of  course  to  define 
character  shapes  in  the  data  base  like  other  picture  elements,  and  in  fact,  this  is  necessary'  if 
characters  are  to  be  treated  like  other  objects,  i.e.,  rotated,  clipped,  etc.  However,  it  is 
possible  to  derive  efficiencies  from  the  foreknowledge  of  character  properties  when  they  do 
not  require  such  sophisticated  treatment,  by  generating  the  actual  strokes  of  the  characters 
just  prior  to  drawing  them  and  dealing  only  with  character  codes  up  to  that  point. 

A hardware  device  which  accepts  character  codes  and  produces  the  strokes  comprising 
the  character  is  called  a Character  Generator. 

To  use  the  generator  to  draw  a string  of  characters,  a display  program  must  first 
stipulate  character  size,  shape  and  orientation  values;  then  position  to  where  the  string  is  to 
begin  and  insert  a set  of  packed  character  codes,  called  a text  string,  into  the  display  file. 
"Hie  Character  Generator  would  then  interpret  the  text  string,  look  up  the  set  of  strokes 
associated  with  each  code,  .size  and  orient  the  strokes  properly,  and  draw  the  characters  on 
the  output  device.  Codes  are  packed  into  text  strings  as  n memory  conservation  measure. 

2. 1.3. 1.5  Picture  interaction 

Graphics  applications  requin*  that  the  form  or  content  of  the  picture  be  changeable  by 
the  user.  A number  of  input  devices  for  this  purpo.se  have  lieen  made  available. 

Function  switches  and  lights  are  attached  to  the  computer  in  the  graphics  system.  These 
are  toggle  switches  or  push  buttons  from  which  polarity  can  be  read.  Kach  switch  can  be 
assigned  a meaning  unique  to  the  program 

Analog  input  devices,  including  control  dials,  ,ire  also  used  for  interaction.  These  devices 
offer  one  or  more  degrees  of  freedom  over  which  a user  can  enter  input  values  usi'd  for 
translation,  scaling,  etc. 
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A versatile  interactive  input  device  is  the  Tablet  and  Pen,  which  is  a flat  rectangular  plate 
which  may  be  positioned  on  a table  in  front  of,  or  near,  the  display  screen.  Associated  with 
the  tablet  is  a pen  which  may  be  moved  about  over  the  plate.  Its  position  on  the  plate  may 
be  read  with  fine  resolution  by  the  computer  controlling  the  system.  The  computer  can  also 
detect  whether  the  pen  is  actually  touching  the  plate  and  may  also  indicate  if  the  pen  is  near 
the  plate.  To  tie  pen  motion  together  with  a picture,  a cursor  is  usually  drawn  on  the  screen. 
'Hiis  cursor  is  a small  symbol  which  continually  moves  about  in  concurrence  with  the  pen.  It 
soon  becomes  natural  to  guide  the  cursor  to  a desired  position  on  the  screen  by  an 
appropriate  motion  of  the  pen. 

The  tablet  can  also  be  programmed  to  perform  the  functions  of  function  switches  or  the 
analog  devices.  In  order  to  enable  a tablet  to  perform  the  pointing  function  of  typical  light 
pen,  the  system  should  be  equipped  with  a hit  test  feature  which  checks  all  data  as  it 
emerges  from  the  transformation  stage  for  proximity  to  the  pen  position.  The  user  positions 
his  cursor  over  the  target  structure  and  initiates  the  hit  test  feature  (perhaps  by  touching  the 
pen  down).  If  a target  structure  is  encountered,  a flag  is  set  which  may  be  later  tested  or 
may  be  programmed  to  cause  an  interrupt.  This  method  of  pointing  has  the  advantage  that 
the  target  structure  is  marked  in  the  data  base,  not  the  display  file.  It  is  often  difficult  or 
impossible  to  backtrack  from  an  entry  in  the  display  file  to  find  its  corresponding  entry  in 
the  data  base. 


The  user  of  the  tablet  is  allowed  to  sit  in  a natural  writing  position  and  at  any  desired 
distance  from  the  graphic  display.  This  reduces  user  fatigue  and  improves  operating 
conditions. 

2.1.3.1.6  Overview  of  the  Picture  System  hardware 

This  section  provides  an  overview  of  the  hardware  components  which  comprise  the 
Piclttre  System.  A functional  diagram  of  the  configuration  of  the  system  is  shown  in  Figure 
2.1. 3.1-9.  The  user  of  the  system  will  normally  interface  with  these  components  by  means 
of  the  Graphics  Software  Package  described  in  a later  section. 


2.1 .3.1. 6.1  The  Picture  Controller.  The  Picture  Controller  in  the  Picture  System  is  a 
Digital  Equipment  Corporation  PDP-11  General  Purpose  Digital  Computer.  Software 
available  for  the  system  includes  a Text  Editor,  Macro  Assembler,  Linker,  Pile  Utility 
Packages,  Debugging  Packages,  and  higher  level  languages  including  BASIC  and  FORTRAN. 
The  availability  of  these  software  systems  and  the  Graphics  Software'  Package  provided  with 
the  Picture  System  enable  the  PDP-11  to  act  as  the  Picture  Controller. 


98 


Fifurt  Functioiwl  configuration  of  Picture  Syttom. 


I 

The  Picture  Controller  is  used  to: 


1.  Contain  the  data  base  which  describes  the  object(s)  to  be  viewed, 

2.  Control  the  processing  of  the  object  coordinate  data  by  the  Picture  Processor, 

3.  Perform  all  input  and  output  required  to  facilitate  graphical  interaction, 

4.  Compute  parameters  for  use  in  simulation  of  object  movement,  data  representation. 


etc.. 
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5.  Perform  all  standard  operating  functions  required  by  the  operating  system  under 
which  the  control  program  executes. 

The  Picture  Controller  communicates  with  the  Picture  Processor  shown  in  Figure 
2. 1.3. 1-9  by  an  Interface  Channel.  By  means  of  this  interface,  all  commands  and  data  are 
communicated  to  the  Picture  Processor.  Refresh  Buffer,  and  Picture  Generator. 

The  following  describes  the  functional  specification  of  the  Picture  Controller. 

1.  General  Functions:  contains  the  data  base,  executes  the  display  programs,  performs 
input/output  operations, 

2.  Computer:  DEC  PDP-11/50,  16-bit  word  size, 

3.  Dimension  Modes:  the  Picture  System  displays  two-  and  three-dimensional  objects, 

4.  Two-dimensional  data  require  two  words  of  Picture  Controller  memory  to  store  the 
X and  y coordinate  values  of  a point, 

6.  Three-dimensional  data  require  three  words  of  Picture  Controller  memory  to  store 
the  X,  y,  and  z coordinate  values  of  a point. 

6.  Homogeneous  coordinate  data  representation  can  be  used  with  the  Picture  System  in 
order  to  provide  a much  larger  effective  dynamic  range  by  scaling  the  normal 
two-dimensional  and  three-dimensional  data. 

7.  Coordinate  Specification  Modes:  Absolute  coordinates  (A)  used  to  define  points 
which  are  a given  displacement  from  the  origin  of  the  data  space. 

8.  Relative  coordinates  (R)  used  to  define  points  which  are  a given  displacement  from 
the  previous  set  of  coordinates. 

9.  Picture  elements  may  be  specified  in  any  of  the  following  sequences  of  coordinate 
point  definitions; 

a.  A,A,A,A,.  . . , 

b.  A.R.R.R,.  . . , 

c.  R,R,R,R,.  . . , 

10.  Drawing  Modes:  The  Move  (M)  moves  the  beam  position  to  a specified  location 
with  the  beam  intensity  off. 

11.  The  Draw  To  mode  (DT)  draws  a straight  line  from  the  current  beam  position  to  a 
new  specified  location  and  leaves  the  beam  position  at  a new  location. 

12.  The  Dot  mode  (D)  moves  the  beam  position  to  a specified  location  with  the  beam 
intensity  off  and  then  intensifies  the  beam  at  the  specified  location.  The  l>eam 
po.sition  remains  at  the  dot  location. 

13.  The  Character  mode  (C)  draws  the  specified  character  beginning  at  the  current 
character  beam  position  and  then  moves  the  beam  position  with  intensity  off  to  the 
position  where  the  next  character  in  a string  begins. 
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14.  Picture  elements  may  be  drawn  using  any  of  the  above  modes  one  by  one,  or  they 
may  be  drawn  using  any  of  the  following  sequences  of  the  alwve  mixU's: 

a.  M.DT.M.DT, . . . (unconnected  lines), 

b.  M,DT,DT,DT, . . . (lines  connected  end-to-endX 

c.  DT,M,DT,M, . . . (another  mode  sequence  for  unconnectetl  lines), 

d.  DT,DT,DT,DT, ...  (another  mode  sequence  for  lines  connecttnl  end-to-end), 

e.  D,D,D,D, ...  (a  series  of  dots), 

f.  C.C,C,C, . . . (a  string  of  characters). 

15.  Instancing:  A method  of  defining  in  the  data  base  a two-dimensional  or 
three-dimensional  structure  once  and  replicating  it  several  times  in  a picture  in 
different  positions,  sizes  and  orientations. 

16.  Instancing  may  be  performed  to  any  level. 

17.  Parameter  Load/Store:  The  Picture  Controller  can  load  and  store  all  control 
registers,  status  registers,  and  matrix  registers  that  reside  in  the  other  components  of 
The  Picture  System. 

2.1.3.1.6.2  Matrix  Arithmetic  Processor.  The  Matrix  Arithmetic  Processor  consists  of  a 
Transformation  Matrix,  a Transformation  Matrix  Stack,  an  Arithmetic  Unit,  and  a 
Parameter  Register  File. 

The  Transformation  Matrix  is  a 16-bit  word.  This  4x4  matrix  is  used  to  transform 
object  coordinate  data.  It  can  also  be  concatenatetl  with  other  4x4  matrices  to  obtain  a 
combined  transformation. 

The  Transformation  Matrix  Stack  is  a storage  area  where  up  to  four,  4x4  element 
matrices  may  be  “stacked”  or  saved  for  future  recall. 

The  Arithmetic  Unit  performs  all  arithmetic  operations  in  the  Picture  Processor.  This 
includes  subtraction,  addition,  multiplication,  division,  and  normalization. 

The  Picture  Processor  contains  an  array  of  16-bit  registers  into  which  pjirameters 
specifying  viewport  boundaries,  scale  factors,  etc.,  arc  stored  and  may  be  ndrieved. 

The  Picture  Processor  utilizes  thest'  units  to  (lerform  digital  ojierations  on  the  data 
received  from  the  Picture  Controller. 

These  operations  are: 


1.  To  process  twivdimensional  data; 
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2.  To  process  three-dimensional  data; 

3.  To  push  the  Transformation  Matrix  onto  the  Matrix  Stack; 

4.  To  transfer  the  top  4x4  matrix  of  the  Matrix  Stack  into  the  Transformation 
Matrix, 

5.  To  load  the  Transformation  Matrix  with  data  from  the  Picture  Controller’s  memory; 

6.  To  store  the  contents  of  the  Transformation  Matrix  into  the  Picture  Controller’s 
memory; 

7.  To  concatenate  the  contents  of  the  Transformation  Matrix  with  a 4 x 4 matrix  in 
the  Picture  Controller’s  memory  to  obtam  a compound  transformation; 

8.  To  load  and  store  the  registers  of  the  Picture  Processor; 

9.  To  check  transformed  coordinate  data  for  visibility  by  comparison  with  a 
two-dimensional  or  three-dimensional  viewing  window— lines  or  portions  of  lines 
outside  the  window  are  removed  by  a clipping  process  so  that  only  visible  segments 
are  processed  further,  and  at  this  point  three-dimensional  data  are  converted  to  two 
dimensions  by  computing  perspective  or  orthographic  views; 

10.  To  perform  a linear  mapping  of  points  from  the  object’s  coordinate  system  into  that 
of  the  Picture  Display. 

Each  data  coordinate  that  is  transformed  may  be  written  into  the  Refresh  Memory’  by 
the  Terminal  Control  to  become  a portion  of  the  new  frame. 

2.1. 3.1. 6.3  Terminal  Control.  The  Terminal  Control  is  the  unit  of  the  Picture  Processor 
that  controls  the  refresh  of  pictures  seen  on  the  Picture  Display.  The  function  of  the 
Terminal  Control  is  to  receive  data  from  the  Matrix  Arithmetic  Processor  and  store  it  in  the 
write  portion  of  the  Refresh  Buffer.  It  is  usually  concurrently  reading  data  from  the  read 
portion  of  the  Refresh  Buffer  and  sending  it  to  the  Picture  Generator. 

The  following  describes  the  functional  specifications  of  the  Picture  Processor; 

General:  — The  Picture  Processor  operations  are  implemented  in  digital  hardware. 

Transformations:  — lYanslates  objects  in  any  direction  in  three  space. 

— Rotates  objects  about  any  axis  in  three  space. 

— Scales  objects  with  respect  to  any  of  the  dimensions  in  three  spai'e. 

— Perspective  transformations  can  be  performed  on  data  passed  to  the 
Picture  Processor. 

— The  Transformation  Matrix  is  expressed  in  homogeneous  coordinates 
which  allow  much  larger  translational  values  than  would  otherwise  be 
possible. 
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— Croates  mirror  imagos  of  ohjoots  atioiit  a plant*. 

Compound 

Transformations:  — Multiplies  transformation  matrices  toRether  while  maintaininR  full-word 
accuracy. 

— The  Transformation  Matrix  may  he  loatlwl  from  tlu*  data  base  or  stored 
into  the  data  bast*  residing  in  the  Picturt*  Controller  memory. 

— There  is  a push-down  stack  for  storing  four  full  transformation  matrices 
with  provision  for  continuing  the  stack  in  the  Picture  Controller 
memory. 

Clipping:  — Kxtracts  the  portions  of  the  objects,  defined  in  the  data  base,  that  are 

within  a program-specified  field  of  view. 

— In  two  dimensions,  the  field  of  view  is  a program-specified  rectangular 
o'gion  of  the  data  space. 

— In  three  dimensions,  the  field  of  view  is  a pyramid  or  frustum 
(truneatt‘d  pyramid)  in  the  data  space  who.se  apex  is  at  the  eye. 

— ('lipping  is  jM'rformed  with  respect  to  the  program-controlled  six 
surfaivs  of  the  frustum. 


Perspective:  Displays  realistic  line  representations  of  three-<limensional  objects  as 

they  appear  to  the  eyt*  with  refen'nce  to  relative  distance  or  depth. 

Viewport:  — The  viewport  specification  is  under  program  control  and  defines  a six 

surface  region  of  the  Pictim*  Display  where  the  pictim*  is  to  appear. 
DaUi  which  has  been  transformetl,  clipped,  and  put  in  perspective  is 
linearly  mapped  into  the  viewport  which  allows  complete  separation  of 
the  coordinaU*  sysU'ms  of  the  drawing  space  and  the  Picture  Display. 

— The  re.solution  of  the  data  mapped  into  the  viewport  is  16  bits,  which 
allows  these  data  to  be  used  for  pmcision  plots. 

— Multiple  viewports  may  lie  defined  for  a given  frame  to  give 
simultaneous  screen. 

— Specification  of  viewport  front  and  back  provides  the  intensity  bounds 
for  depth-<’ueing. 

Zooming:  — The  Pictun*  Processor  allows  for  moving  smoothly  and  quickly  into  (or 

out  of)  a complex  data  strvicture  in  order  to  obtain  a more  detailed  (or 
wide  angle)  view  of  a chosen  region  in  the  drawing  space. 

Hit  Test:  — 'Ihe  Picture  System  can  detect  whether  any  (lart  of  a given  (licture 

element  is  within  a program-specified  region  in  the  data  s|)ace  or  on  the 

— Picture  Display.  Hit  Test  is  used  for  implementing  the  (lointing  function 
with  a data  tablet,  eliminating  the  nwd  for  a light  pen. 
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Memory  Write 
Back: 


— Under  program  control,  transformed  digital  data  can  be  written  back 
into  the  Picture  Controller’s  memory  to  drive  a hard  copy  plotter,  for 
example,  or  as  data  for  further  computation. 

2.1.3.1.6.4  The  Refresh  Buffer.  The  Refresh  Buffer  is  a memory  (distinct  from  (he 
Picture  Controller’s)  into  which  processed  data  is  depo.sited  still  in  digital  form.  This  data 
represrmts  the  picture  to  be  displayed  on  the  Picture  Display.  For  each  frame  refre.sh,  the 
Terminal  Control  reads  the  data  in  the  Refresh  Buffer  and  passes  the  data  to  the  Picture 
(leneralor,  where  the  data  is  converted  to  analog  signals  to  drive  the  Picture  Display. 
Character  strings  from  the  Picture  Controller  pa.ss  through  the  Picture  Proces.sor  unmodified 
ami  are  dept)siU‘d  in  the  Refresh  Buffer  as  packed  characU'r  codes. 


The  Refresh  Buffer  may  be  operated  in  single  or  double  buffer  mode  under  program 
control.  In  single  buffer  mode,  the  entire  Refresh  Buffer  is  used  to  ston*  a single  display 
frame.  In  this  mode,  display  refresh  may  be  initiated  from  partially  updated  display  frame. 
In  double  buff€*r  mode,  one  half  of  the  refresh  buffer  is  designated  as  an  old  frame  and 
one-half  a new  frame.  Display  refresh  is  then  initiaUxl  from  the  old  frame,  while  the  new 
frame  is  being  constructed.  When  the  construction  of  the  new  frame  is  complete,  the  frame 
buffers  are  swapped  and  the  newly  constructed  frame  is  displayed  and  the  space  occupied 
by  the  old  frame  becomes  available  for  new  frame  constniction. 

The  following  describes  the  functional  specification  of  the  Refresh  Buffer. 


General 

Function; 


Data  (,'onUMit: 


Buffering: 

(.’ursor: 


— The  Refresh  Buffer  stores  processetl  digital  frame  data  allowing 
complete  separation  of  Picture  Display  refresh  requirements  from  the 
dynamic  picture  update  requirements. 

— Dots  and  line  endpoint  data  for  use  by  the  Picture  Generator  (one 
complete  dot  or  line  endpoint  definition  }x*r  buffer  entry  containing  12 
bite  for  each  of  the  x and  y coordinate  values  and  8 bite  for  the 
intensity  value). 

— Packed  character  codes  for  use  by  the  Character  Generator  (up  to  thn*e 
codes  per  buffer  entry). 

— Status  information  ust'd  to  control  the  displaying  of  the  data. 

— Program-selectable  single  or  double  buffering  is  standard. 

— A dynamic  cursor  can  Iw  maintained  regardless  of  the  frame  update 
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Size*:  — In  single  buffer  inode,  up  to  8,188  dots,  line  endpoints,  or  character 

iHjde  entries  can  be  stored  in  the  buffer  in  any  combination. 

— In  double  buffer  mode,  up  to  4,092  dots,  line  endpoints,  or  character 
code  entries  can  be  stored  in  the  buffer  in  any  combination. 

2. 1.3. 1.6.5  Character  Generator.  CharacU*r  strings  from  the  Picture  Controller  pass 
through  tlie  Picture  I’rocessor  unmodified  and  are  deposited  in  the  Refresh  Buffer  as  packed 
character  codes.  Then  characU'r  words  are  read  out  of  the  Refresh  Buffer;  the  Terminal 
Control  tt'cognizes  thest'  codes  and  calls  upon  the  Character  Generator  to  access  a read-only 
memory  containing  characU'r  stroking  data.  The  strokes  am  read  out  of  the  read-only 
memory  one  by  one,  multiplied  by  a pre-specified  sizing  parameter,  and  drawn  by  the 
lhctur»>  Generator  on  the  Picture  Display. 

The  following  describes  the  functional  specifications  of  the  Character  Generator. 

General 

Function:  — .Accepts  character  codes  and  produces  provierly  sized  digital  character 

stroking  data  for  the  Picture  Generator. 

CharacU'r  Set:  — 96  characU'r  exU'nded  ASCII  characU'r  set. 

Sizes:  — Then'  are  8 characU'r  sizes  available  under  program  control  ranging 

from  0.07  in.  high  in  increments  of  0.07  in.  to  0.56  in.  high  on  the 
l*ictun'  Display.  The  character  width  is  also  under  program  control  with 
8 different  widths  st'lectable  for  each  size. 

Character 

Orientation:  — Horizontal  90"  counter-clockwise  orientation. 

Capacity:  — A maximum  of  1,725  characU'rs  can  be  displayed  at  a mfresh  rate  of  80 

frames  jier  second. 

2. 1.3.1. 6.6  The  Picture  Generator.  The  Picture  Generator  receives  digital  data 
consisting  of  x,y  coordinaU'  and  intensity  information  read  from  the  Refre.sh  Memory  by 
the  Terminal  Control  Unit.  These'  digital  data  are  converU'd  by  the  Picture'  Generator  into 
analog  signals  anel  iisenl  to  draw  the  picture  on  the  Pictum  Display. 

2. 1.3. 1.6.7  The  Picture  Display.  The  Pictura  Display  receive's  analog  .signals  frenn  the 
1‘ictun'  Gene'rator  which  an'  use'd  for  e'lectron  be'am  positioning  and  inU'iisily  control.  The' 

*The  SUmlard  RefrMh  Buffer  i*  8K.  36-bit  words.  An  additional  8K  of  Refresh  Memory  may  l>e  obtained 
by  providing  a 16K  Refresh  Buffer. 
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Picture  Generator  controls  beam  positioning  and  the  drawing  of  all  vectors  and  dots  on  the 
Picture  Display.  The  following  describes  the  functional  specification  of  the  Picture 
Generator  and  Picture  Display. 


General  Function: 

Line  Modes: 


Intensity  Modes: 


Intensity  and 
Contrast  Controls: 


Refresh  Control: 
Display  Rates: 


Display  Type: 


— Converts  digital  coordinate  and  intensity  information  to  analog 
voltages  to  drive  an  electron  beam  across  a phosphor-coated  surface. 

— Solid. 

— Blink  mode  allows  set  cted  picture  elements  to  blink  on  and  off. 

— Dash  mode  allows  selected  lines  of  a picture  to  be  dashed. 

— Constant  intensity  of  program-selected  picture  elements  may  be 
chosen  from  256  levels.  Lines  are  drawn  at  a constant  rate  which 
assures  uniform  brightness  for  the  chosen  intensity  level. 

— Depth-cueing  allows  the  intensity  of  lines  to  vary  continuously  with 
depth  (i.e.,  the  z coordinate  of  the  display). 

— In  order  to  present  a uniform  variation  in  brightness,  the  intensity 
control  of  the  Picture  Display  treats  the  z coordinate  data  as  the 
logarithm  of  the  intensity  to  be  shown  on  the  display. 

— The  contrast  control  of  the  Picture  Display  is  completely 
independent  of  the  intensity  control. 

— The  refresh  cycle  is  controlled  by  synchronization  with  the  power 
line. 

— Move  Time  (for  an  n in.  move) 

< .41  X n + 2.85  jus  for  n > 1/2  in. 

<3.0 /us  for  n>  1/2  in. 

— Draw  Time  (for  an  n in.  line) 

< 1.85  X n + 2.0  /us  for  n > 1/2  in. 

<3.0 /us  for  n<  1/2  in. 

— Dot  Time  (for  dots  spaced  n in.  apart) 

< .5  X n + 4.9  /us  for  n > 1/2  in. 

<5.15  us  for  n<  1/2  in. 

— Approximate  display  capacities  at  30  frames  per  second  refresh  rate: 

1.  11,100  connected  1/2  in.  lines 

2.  1,625  connected  10  in.  lines 

3.  6,650  dots  1/4  in.  apart 

4.  1,725  characters  .14  in.  high  (average) 

5.  1,500  characters  .56  in.  high  (average) 

— Calligraphic. 
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Deflection  Typ 

Spot  Size: 

Addressable 

Locations: 

Endpoint 

Matching: 

CRT  Size: 
Phosphor: 


— Electromagnetic 

— 0.020  in. 

— 4,096  X 4,090. 

— 0.020  in. 

— 21  in.  rectangular,  10  in.  X 10  in.  quality  viewing  area. 
-p4. 


2.1.3.1.6.8  Data  Input  All  data  is  input  directly  to  the  Picture  Controller  in  the 
Picture  System.  Data  may  be  input  by  any  of  the  various  standard  peripherals  available  with 
the  PDP-11  or  by  any  of  four  graphical  input  devices  supported  by  the  Picture  System: 

1.  Tablet, 

2.  Control  Dials, 

3.  Function  Switches  and  Lights, 

4.  Alphanumeric  Keyboard. 


The  use  of  these  standard  graphical  input  devices  provides  all  the  capabilities  normally 
required  for  graphical  interaction  with  the  Picture  System. 


2. 1.3. 1.6.9  The  Tablet  and  Pen.  The  Tablet  serves  as  the  standard,  general  purpose 
graphic  input  device  in  the  Picture  System.  The  Tablet  can  be  used  for  positioning  or 
pointing  to  the  picture  elements  by  use  of  the  Pen  whose  x,y  coordinates  are  read  by  the 
Picture  Controller.  A “cursor”  may  be  drawn  on  the  Picture  Display  to  indicate  the  position 
of  the  Pen  on  the  Tablet.  With  these  capabilities,  the  Tablet  and  Pen  can  perform  the 
interactive  functions  usually  reserved  for  such  graphic  input  devices  as  light  pens,  joy  sticks, 
and  function  switches.  The  Tablet  is  fully  software-supported  under  the  Graphics  Software 
Package  provided  with  the  system. 


The  following  describes  the  functional  specification  of  the  Tablet. 


General: 

Output: 

Resolution: 


— General  purpose  interactive  input  device. 

— 11  bits  of  X,  11  bits  of  y,  and  pen  up/down  status. 

— Digital:  11  bits  for  both  x and  y. 

— Graphic:  100  lines  per  in. 


Sampling  Rate:  — Variable  up  to  200  samples  per  sec. 
Size:  — 11  in.  x 11  in.  useful  area. 


107 


Cursor:  — The  cursor  location  on  the  Picture  Display  may  be  made  to  correspond 

to  the  stylus  pen  position  on  the  tablet. 

2.1.3.1.6.10  Control  Dials.  Control  Dials  are  available  with  the  System  which  permit 
the  user  to  dynamically  vary  values  which  may  be  used  to  control  angles  of  rotation,  scaling 
factors,  velocity  rates,  etc. 

2.1.3.1.6.11  Function  Switches  and  Lights.  F'unction  switches  and  lights  are  available 
with  the  Picture  System  to  provide  the  capability  for  the  user  to  utilize  switches  to  be  used 
for  functions  assigned  under  program  control.  An  additional  capability  available  with  the 
switches  is  that  the  lights  (one  per  switch)  may  be  used  to  indicate  function  switch  polarity 
or  for  displaying  programmed  information. 

2.1.3.1.6.12  Alphanumeric  Keyboard.  The  Alphanumeric  Keyboard  available  with  the 
Picture  System  is  a standard  61-key,  128-character  keyboard  which  may  be  used  for  text  or 
data  input  to  the  Picture  Controller  for  graphical  interaction  or  other  functions  required  by 
the  user. 

2. 1.3. 1.7  The  Picture  System  Graphics  Software  Package 

The  Graphics  Software  Package  furnished  with  the  Picture  System  consists  of  a set  of 
FORTRAN-callable  subroutines  written  for  the  Digital  Equipment  Corporation  PDP-11 
computer  using  the  MACRO-11  assembly  language.  These  subroutines  are  written  with  the 
intent  of  providing  a user  with  the  full  capabilities  of  the  Picture  System  without  the 
necessity  of  the  user  to  interface  on  a system  level  with  the  system  hardware.  These 
subroutines  provide  the  general  user  with  the  facilities  necessary  for  writing  interactive 
computer  graphics  programs  without  having  to  comprehensively  understand  the  matrix 
arithmetic  utilized  within  the  System  Processor.  Instead,  the  user  merely  "calls”  a 
subroutine  to  perform  a required  graphical  function,  i.e.,  TRANslate,  ROTate,  SCALE,  read 
TABLET  information,  display  CURSOR,  display  TEXT,  etc. 

The  graphics  subroutines  for  the  Picture  System  have  been  written  utilizing  the  PDP-11 
FORTRAN  calling  sequence  convention  of  the  PDP-11  FORTRAN  compiler  V06.  This 
calling  sequence  convention,  supported  under  the  DEC  RT-11,  DOS/BATCH,  RSX-llM  and 
RSX-llD  operating  systems,  provides  the  user  with  flexibility  of  utilizing  argument  lists 
that  are  re-entrant  or  non-re-entrant  in  form. 

All  FORTRAN — callable  Picture  System  subroutines  use  the  standard  call  by  name  (as 
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opposed  to  call  by  value)  parameter  passing  technique  and  specify  the  non-re-entrant  inline 
form  of  calling  sequence.  Those  subroutines  which  are  not  FORTRAN-callable  specify  no 
FORTRAN  calling  sequence. 

The  System  Graphics  Software  Package  may  be  separated  into  two  sets  of  subroutines: 

1.  User  Subroutines, 

2.  System  Subroutines. 

The  User  Subroutines  provide  all  the  capabilities  required  for  the  general  graphical 
application  programmer.  The  System  Subroutines  are  utilized  to  implement  the  User 
Subroutines  and  are  available  to  the  programmer  who  wants  to  interface  with  the  system 
software  directly. 

A brief  description  of  each  subroutine  is  contained  in  the  following  sections. 

2.1. 3.1.7. 1 User  Subroutine  PSINIT.  The  PSINIT  subroutine  is  cedled  to  initialize  the 
Picture  System  hardware  and  software.  The  initialization  process  includes  the  following: 

1.  The  system  Real-Time  Clock  interrupt  handler  is  connected  to  the  interrupt  vector 
and  set  to  provide  automatic  refresh  of  the  old  frame  and  timing  for  frame  update  at 
the  intervals  specified  by  the  calling  argument  list; 

2.  All  variables  are  assigned  their  default  values;  all  registers  used  in  the  Picture 
Processor  are  initialized  for  two-dimensional  drawing  mode;  the  Picture  Processor  is 
set  to  display  data  unrotated,  untranslated,  at  full  brightness,  within  a viewport 
which  just  fills  the  display  screen; 

3.  A window  is  set  to  include  the  entire  definition  space  (±32767); 

4.  The  Refresh  Buffer  is  set  to  double  buffer  mode  with  an  initial  frame  consisting  of  a 
null  cursor;  the  Picture  Generator  status  is  initialized  to  solid,  0.28  in.  character  size, 
and  horizontal  character  mode; 

5.  All  Picture  Displays  are  selected  for  output. 

2.1.3.1.7.2  User  Subroutine  VWPORT.  The  VWPORT  subroutine  is  called  to  set  a 
viewport  specified  by  the  values  supplied  by  the  operator  within  the  calling  parameters. 

2.I.3.I.7.3.  User  Subroutine  WINDOW.  The  WINDOW  subroutine  concatenates  a 
two-dimensional  or  three-dimensional  windowing  transformation  to  the  Picturt'  Processor 
Transformation  Matrix.  This  subroutine  can  be  used  to  perform  twoHlimensional 
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windowing,  orthographic  projection  or  a true  perspective  transformation  of  data.  The 
windowing  transformation  is  constructed  from  the  arguments  specified  in  the  parameter  list. 

Z 1.3. 1.7.4  User  Subroutine  ROT.  The  ROT  subroutine  is  called  to  build  a rotation 
transformation  based  on  the  angle  and  axis  of  rotation  specified  in  the  parameter  list.  The 
transformation  is  then  concatenated  to  the  Picture  Processor  Transformation  Matrix. 

! 

2.1. 3.1. 7.5  User  Subroutine  TRAN.  The  TRAN  subroutine  is  called  to  build  a 
translation  transformation  based  on  the  x,  y,  and  x translational  values  specified  in  the 
parameter  list.  The  transformation  is  then  concatenated  to  the  Picture  Processor 

^ Transformation  Matrix. 

1 

i 2. 1.3. 1.7.6  User  Subroutine  SCALE.  The  SCALE  subroutine  is  called  to  build  a scaling 

\ transformation  based  on  the  x,  y,  and  z scaling  terms  specified  in  the  parameter  list.  The 

I transformation  is  then  concatenated  to  the  Picture  Processor  Transformation  Matrix. 

‘ i 

I ] 2.1.3.1.7.7  User  Subroutine  PUSH.  The  PUSH  subroutine  is  called  to  push  the  current 

f j Picture  Processor  Transformation  Matrix  onto  the  matrix  stack  (hardware  or  memory  stock, 

I dependent  upon  the  current  stack  depth). 

' t 

; 2. 1.3. 1.7.8  User  Subroutine  POP.  The  POP  subroutine  is  called  to  pop  the  top  element 

of  the  matrix  stack  (hardware  or  memory  stack,  dependent  upon  the  current  stack  depth) 
into  the  Picture  Processor  Transformation  Matrix. 

2.1. 3.1. 7.9  User  Subroutine  DRAWZD.  The  DRAWZD  subroutine  is  called  to  draw 
two-dimensional  data  coordinate  points  using  the  drawing  mode  specified  in  the  parameter 
list.  The  data  to  be  drawn  are  arranged  in  x,y  pairs  and  are  displayed  at  the  intensity 
specified  by  the  IZ  parameter. 

' 2.1.3.1.7.10  User  Subroutine  DRAW3D.  The  DRAW3D  subroutine  is  called  to  draw 

three-dimensional  data  coordinate  points  using  the  drawing  mode  specified  in  the  parameter 
! list.  The  data  to  be  drawn  are  arranged  in  x,y,z  triplets  and  are  displayed  at  the  intensity 

dependent  upon  the  z coordinates  and  the  values  specified  for  the  hither  and  yon  planes. 

2.1.3.1.7.11  User  Subroutine  CHAR.  The  CHAR  subroutine  is  called  to  update  the 
status  used  by  the  Character  Generator  when  characters  are  to  be  displayed  on  the  display 
screen. 


t 
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2.1.3.1.7.12  User  Subroutine  TEXT.  The  TEXT  subroutine  is  called  to  display  the  text 
string  specified  in  the  parameter  list.  The  display  of  the  text  will  be  from  the  current  beam 
position  and  at  the  intensity  associated  with  the  last  information  displayed.  The  character 
status  will  be  initialized  by  PSINIT  or  updated  by  the  CHAR  subroutine  if  previously  called 
by  the  user. 


2.1.3.1.7.13  User  Subroutine  INST.  The  INST  subroutine  concatenates  a 
two-dimensional  or  three-dimensional  instancing  transformation  to  the  Picture  Processor 
Transformation  Matrix.  This  subroutine  is  used  in  conjunction  with  the  MASTER 
subroutine  to  produce  multiple  instances  of  an  object  or  symbol.  For  each  desired 
appearance  of  the  object,  the  INST  subroutine  is  called  to  specify  the  location  (and 
implicitly  the  size)  of  that  appearance;  then  the  user-supplied  routine  describing  the  object 
is  called  to  display  the  object  previously  defined  within  a two-dimensional  or 
three-dimensional  enclosure.  The  INST  subroutine  pushes  the  initial  Transformation  Matrix 
onto  the  Transformation  Stack  before  concatenating  the  instancing  transformation,  so  that 
it  may  be  restored  (transferred)  by  the  user  after  the  object  has  been  drawn. 

2.1.3.1.7.14  User  Subroutine  MASTER.  The  MASTER  subroutine  concatenates  a 
two-dimensional  or  three-dimensional  master  transformation  to  the  Picture  Processor 
Transformation  Matrix.  This  subroutine  is  used  in  conjunction  with  the  INST  subroutine  for 
instancing  of  data.  The  master  transformation  is  constructed  from  the  arguments  specified 
in  the  parameter  list. 


2.1.3.1.7.15  User  Subroutine  DASH.  The  DASH  subroutine  is  called  to  set  the  Picture 
Generator  status  such  that  all  subsequent  lines  drawn  will  be  dashed  or  nondashed 
dependent  upon  the  value  of  the  argument. 

2.1.3.1.7.16  User  Subroutine  BLINK.  The  BLINK  subroutine  is  called  to  set  the 
Picture  Generator  status  such  that  all  subsequent  lines  drawn  will  cr  will  not  blink, 
dependent  upon  the  value  of  the  argument.  Data  drawn  in  Blink  mode  will  blink  at 
approximately  90  blinks  per  minute. 

2.1.3.1.7.17  User  Subroutine  SCOPE.  The  SCOPE  subroutine  is  called  to  select  the 
Picture  Display  to  which  output  will  be  directed. 

2.1.3.1.7.18  User  Subroutine  TABLET.  The  TABLET  subroutine  is  called  to  read  the 
current  pen  position  and  status  in  relation  to  the  tablet.  The  user  may  also  specify  initiation 
of  automatic  tablet  mode.  This  will  cause  the  cunent  pen  position  to  be  updated  at  each 
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fnime  refrosli.  This  ability,  uswl  in  conjunction  wiili  the  automatic  cursor  motle,  allows 
compleU'ly  dynamic  cursor  tracking  irrespective  of  new  frame  update  rate.  It  should  be 
notwl  that  once  the  pen  information  is  updated  with  the  pen  down  bit  set,  the  pen  position 
will  not  be  updatiH.!  until  the  user  has  cleared  the  pen  value  wort!  indicating  that  the  pen 
down  position  has  been  read  or  until  the  pen  is  .set  down  again. 

2.1.3.1.7.19  User  Subroutine  ISPDWN.  ISl’DWN  (IS  I’.VN  DOWN)  is  a FORTR.VN- 
callable  integer  function  subroutine  which  may  lie  lists.!  to  determine  whether  the  pen  is 
down  (i.e..  pressed  against  the  surface  of  the  tablet).  This  function  routine  allows 
FORTR.\.\  a(iplications  programs,  which  do  not  have  the  ability  to  perform  bit  testing,  to 
test  the  pen  u{>  'tlown  sUitus. 

2.1.3.1.7.20  User  Subroutine  CURSOR.  The  CURSOR  subroutine  is  called  to  ilisplay  a 
cursor  at  the  position  specifusl  by  the  parameter  list.  This  will  cause  a cursor  to  be  displayw! 
upon  each  frame  refresh  irrespective  of  the  new  frame  update  rate.  The  cursor  displayed  in 
automatic  cursor  mode  will  be  at  die  position  sptvifietl  by  the  x and  y position  values  and 
within  the  viewport  that  had  In't'ii  specified  at  the  time  of  the  initial  CURSOR  call.  The 
cursor  displaywl  consists  of  a cross  with  a center  at  the  x and  y position  spivifiixi. 

2.1.3.1.7.21  User  Subroutine  HITWIN.  The  III  TWIN  subroutine  is  calUxl  to  sptvify  a 
window  through  which  data  will  be  passix!  to  determine  whether  data  are  being  drawn 
within  a given  area.  The  user  sptvifies  an  x and  y coonlinate  where  a window  transformation 
of  the  spwified  size  is  centered.  This  window  transformation  is  then  pre-concatenatwi  with 
the  transformation  in  the  Picturt'  Processor  Transformation  Matrix,  after  first  saving  the 
original  transformation  so  that  it  may  Ih'  restored  after  all  hit  testing  has  been  completed. 
The  Picture  Processor  status  is  then  set  to  prohibit  all  data  drawn  from  being  output  to  the 
Refresh  Buffer.  The  subroutine  then  returns  to  allow  the  user  to  draw  all  data  against  which 
hit  testing  is  to  be  performetl. 

2.1.3.1.7.22  User  Subroutine  HITEST.  The  lUTKST  subroutine  is  ciiIUhI  to  determine 
if  any  output  data  has  passwl  within  a pri'specified  hit  window  (see  HITWIN).  'I'he  proce- 
dure for  this  test  is  of  the  form; 

1.  CALL  HITWIN  to  set  up  the  desired  hit  window, 

2.  Draw  data  (I)RAW2D  and/or  DR.\W3D)  for  comparison  against  that  window, 

3.  CALL  HITEST  to  determine  if  there  was  a "hit", 

4.  Repeat  steps  two  and  three  as  often  as  necessary,  setting  HITEST  argument  two  to  a 
non-zero  value  on  the  last  call  to  HITEST  to  restore  the  former  user  transformation. 


112 


i 


2.1.3.1.7.23  User  Subroutine  NUFRAM.  The  NUFRAM  subroutine  is  called  to  initiate 
the  switch  from  displaying  the  old  frame  data  to  displaying  the  new  frame  data  (the  actual 
frame  switch  does  not  occur  until  the  appropriate  refresh  interval). 

2.1.3.1.7.24  User  Subroutine  SETBUF.  The  SETBUF  subroutine  is  called  to  set  the 
Refresh  Buffer  to  single-buffer  or  double-buffer  mode.  Once  the  Refresh  Buffer  has  been  set 
to  a mode,  it  may  be  reset  at  any  time  to  the  other  mode.  The  user  needs  to  call  this 
subroutine  only  if  the  Refresh  Buffer  is  used  in  single  buffer  mode.  PSINIT  during  the 
initialization  process  sets  the  Refresh  Buffer  to  the  default  double-buffer  mode. 

2.1.3.1.7.25  User  Subroutine  PSWAIT.  The  PSWAIT  subroutine  is  called  whenever  it  is 
necessary  to  wait  until  the  Picture  Processor  and  Direct  Memory  Access  Unit  have  com- 
pleted their  present  operations  before  continuing.  This  is  used  to  insure  that  the  data 
transfer  to  or  from  the  Picture  Controller’s  memory  is  complete  before  the  data  is  refer- 
enced or  modified. 

2.1.3.1.7.26  System  Subroutine  BLDCON.  The  BLDCON  subroutine  is  calltKl  to 
perform  all  transformation  operations  and  matrix  manipulations. 

2.1.3.1.7.27  System  Subroutine  P$AVE.  The  P$AVE  subroutine  is  called  to  save 
registers  R0-R5  on  the  program  stack. 

2.1.3.1.7.28  System  Subroutine  RSTORE.  The  R$TORE  subroutine  is  called  to  restore 
registers  R0-R5  from  the  program  stack. 

2.1.3.1.7.29  System  Subroutine  P$DMA.  The  P$DMA  subroutine  is  called  to  initiate  a 
Direct  Memory  Access  (DMA)  transfer  and  check  for  the  correct  completion  of  the  opera- 
tion. 

2.1.3.1.7.30  System  Subroutine  l$MATX.  The  l$MATX  subroutine  is  called  to  initial- 
ize a 16-word  array  in  memory  (P$MATX)  to  a 4 x 4 identity  matrix. 

2.1.3.1.7.31  System  Subroutine  ERROR.  The  ERROR  subroutine  is  called  by  all 
Picture  System  subroutines  that  encounter  an  error  condition  during  the  course  of 
execution.  This  subroutine  in  turn  calls  the  ust»r  error  subroutine  specified  in  the  call  to 
PSINIT  or  the  default  system  error  routine. 
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The  following  two  function  subroutines  are  optimized  for  the  particular  PDP-11  hard- 
ware configuration. 

2.1.3.1.7.32  Function  Subroutine  P$DIV.  The  P$D1V  function  subroutine  divides  the 
signed  division  in  RO  and  R1  by  the  signed  divisor  in  R2,  leaving  the  quotient  in  RO  and  the 
remainder  in  R1  with  R2  undisturbed.  The  quotient  l>ears  the  algebraic  sign  of  the  division, 
while  the  remainder  retains  the  sign  of  the  dividend. 

2.1.3.1.7.33  Function  Subroutine  P$MUL.  The  P$MUL  function  subroutine  multiplies 
the  signet!  multiplicand  in  RO  by  the  signet!  multiplier  in  R2,  leaving  a signed  protluct  in  RO 
and  R1  with  R2  undisturbed. 

2.1.3.1.8  Picture  System  errors 

Error  detection  by  the  Graphics  Software  Package  is  performed  to  insurt>  program 
integrity  and  to  facilitate  program  debugging.  .\  user  may  make  four  types  of  programming 
errors  that  will  be  detectet!  by  the  Graphics  Software  Package.  These  are: 

1.  The  call  of  a graphics  subroutine  with  an  invalid  numln'r  of  parameters  sptvified, 

2.  The  call  of  a graphics  subroutine  with  an  invalid  parameter  value. 

3.  The  attempt  by  Uie  user  to  PUSH  the  matrix  stack  to  a depth  greater  than  that 
svH*cified  by  the  user  in  the  call  to  PSINIT, 

4.  The  attempt  by  the  inser  to  POP  a transformation  from  the  matrix  stack  which  had 
not  been  previously  PUSHed. 

When  an  error  is  detected  by  a graphics  subroutine,  the  system  subroutine  ERROR  is 
called  with  an  argument  that  spix-ifies  the  origin  of  the  error  detected  and  the  error  con- 
dition encountertx!.  The  .sy.stem  subroutine  ERROR  then  calls  the  user  error  subroutine, 
specifiw!  in  the  call  to  PSINIT.  When  callw!,  a piuameter  will  Ih'  passtx!  by  the  user  error 
subroutine,  which  specifies  the  origin  and  type  of  error  detecUx!.  Return  from  the  user  error 
subroutine  will  result  in  the  termination  of  the  program.  If,  in  the  call  to  PSINIT,  the  user 
does  not  sptxnfy  an  error  svibroutine.  the  graphics  error  subroutine  PSFRRS  will  Ih>  called. 
PSERRS,  when  calUxl,  will  lie  calhxi.  PSERRS,  when  cjillei!,  will  output  the  following 
me.ssage  to  the  console  terminal.  . . 

ERROR  X DETEtTEl)  IN  GR.XPlllCS  SUBROUTINE  YY, 

. . . .md  terminate  the  execution  of  the  program. 


Becau.se  a compn'hensive  set  of  system  diagnostics  is  provideii  with  the  Picture  System, 
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lianlware  error  detection  is  performed  to  a minimal  level.  I'hert'  are,  however,  two  error 
eotles  whieh  may  indicate  a hanlware  failure.  They  an*: 

1,  2.  Direct  Memory  Access  Error;  This  indicates  that  an  error  occurred  during  the  last  | 

Direct  Memory  Access  operation; 

1,3.  Matri.x  Stack  Error;  This  error  indicates  that  the  Picture  Pro<‘essor  detected  an 
attempt  to  overflow  or  underflow  the  hardware  matrix  stack;  this  error  can  only 
be  caused  by  a hardware  malfunction  or  by  a system  programming  error,  and  if  no 
software  error  is  apparent,  the  PUSH/POP  diagnostic  routine  may  be  run  to  check 
the  integrity  of  the  hardware. 

2.1.3.2  Video  Control  Center 

The  purpose  of  the  Video  Control  Center  is  to  generate,  control,  monitor,  and  record  all 
standard  video  signals  needed  in  the  AVSAIL  simulation  facility.  Video  signals  may  be 
generattxl  live,  from  video  tape,  or  from  movie  film.  The  video  signals  can  be  monitored  at 
the  console  and  distributed  to  a remote  location  such  as  the  cockpit  simulator.  Special 
effei’ts  can  he  used  to  after  the  signal.  Cameras  are  available  to  observe  the  pilot’s 
movements  during  a simulation.  This  information,  as  well  as  all  other  video  signals,  can  be 
rtvortled  on  tape  for  future  reference.  The  system  can  also  starve  as  a training  tool  in  that 
demonstration  and  instruction  tapes  can  be  produced. 

The  Flying  Spot  Scanner  is  designed  to  simulate  a raster  type  sensor  on  an  aircraft.  The 
scanner  is  included  in  this  report  because  it  is  a source  of  video  and  depends  upon  control 
signals  from  the  Video  Control  Center  for  operation.  A photograph  of  the  complete  console 
(with  the  exception  of  the  Flying  Spot  Scanner)  is  shown  in  Figure  2.1. 3.2-1. 

2.1.3.2.1  Video  console 

Figure  2. 1.3. 2-2  is  a sketch  of  the  console  with  the  various  functional  components 
numbered.  A listing  of  these  components  is  given  in  Table  2.1. 3. 2-1.  Each  component  is 
described  briefly  in  the  following  sections. 

.\  standard  video  signal  has  three  main  parts:  SYNC,  BLANKING,  and  VIDEO 
INFORMATION.  Figure  2.1. 3.2-3  defines  these  and  other  terms  used  throughout  this 
discussion. 

2.1. 3.2.1. 1 AC  Power.  Nearly  all  pieces  of  equipment  in  the  console  are  (X)wen'd 
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TAILE  M.IM.  VIDEO  CONSOLE  COMPONENTS 


Contolt  Compontnt  Numbar 

Coniolt  Componanti 

1 

AC  powar 

2 

Vidao  tapa  lyitam 

3 

Camaras 

4 

Syndironiratlon  and  tast  signal  connactors 

S 

Routing  nvitchar 

6 

Monitors 

7 

Spacial  affacts  ganarator 

8 

POP-11  intariaca 

9 

Part  of  flying  spot  scannar 

Figurt  2.1. 3.2-3.  Standird  vidto  signal. 


through  a laU'hing  relay  technique.  (Figure  2.1. 3.2-4.)  The  relay  unit  consisU  of  a relay  box 
that  plugs  into  a rack  power  strip  and  has  one  or  two  120V  AC  outlets  for  the  equipment 
and  a 3-pin  Cinch  connector  for  a control  cable.  The  master  control  panel  has  a momentary 
rtx'ker  switch  and  indicator  light  for  each  relay.  Depressing  the  switch  will  energize  the  relay 
and  cause  it  to  switch  staU'S.  A st'cond  energizing  will  cause  the  relay  to  switch  back 
(latching  impulse  relay).  The  indicator  light  shows  the  state  of  Uie  n'lay  box  output,  hence 
the  status  of  the  equipment  conmx'Unl  to  that  box. 
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The  various  equipments  powered  from  the  switch  panel  are  listed  in  Table  2.1. 3. 2-2. 

Not  all  equipment  power  is  controlled  by  these  relays.  Such  items  as  the  Time  Base 
Correctors  which  have  obvious  power  switches  and  pilot  lights  are  not  controlled  in  order  to 
conserve  relays.  Other  items  such  as  the  146  SYNC  Generator  are  on  continuously  for 
frequency  stability. 

2. 1.3.2. 1.2  Routing  Switcher.  The  routing  switcher  is  the  heart  of  the  video  system. 

(Figure  2. 1.3. 2-5,  -6.)  The  400  crosspoint  video  switcher  selects  and  distributes  video  to  all 
destinations. 

The  purpose  of  the  switcher  is  to  (>erform  a function  equivalent  to  connecting  coa.\ 
from  a video  source  to  a destination  by  merely  pushing  a button.  The  system  also  provides  a 1 

readout  tally  of  completed  circuits. 
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Switch  Label 


CMx 
BMx-v 
520/529 
D AMPS 
P SW 
C CAM  1 
C CAM  2 
C CAMS 
VAE 
Switcher 
SW  lightt 
SW+5 
±15 
lNT+5 


TABLE  2.1.3.2-2.  CONSOLE  POWER  OISTRIBUTION 


Equipment 


Color  monitor  x (0-41 

Monochrome  moniton  5-7, 8-10, 11-12 

520  Vectoracope,  529  Waveform  monitor 

Distribution  amplifiers 

Production  switchers 

IVC  150  camera  and  NTSC  encoder 

IVC  92B  camera  and  NTSC  encoder  (film  chein) 

GE  TE  1000  camera 

Vertical  aperture  equalizers  for  IVC-150  and  92B  cameras 

Main  power  to  routing  switcher 

Switcher  tally  lights 

Switcher  control  interface 

Scanner  ratter  and  POP-1 1 interface 

-fS  supply  to  POP-f  1 interface 


Ftfurc  2.1. 3.2-5.  Routing  switcher. 
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Figure  2.1.3.2-6.  Routing  switcher. 


The  control  inputs  require  TTL  compatible  signals  whereas  the  tally-out  signals  are 
discrete  transistors.  The  interface  circuits  act  as  a buffer/summer  for  incoming  commands 
and  a data  multiplexer  for  returned  tally  information.  The  buffer  input  is  designed  to  accept 
commands  from  more  than  one  source  such  as  from  console  push-buttons,  remote  push- 
buttons or  the  PDP-11. 

The  switcher’s  400  crosspoints  are  arranged  as  10  inputs  and  40  outputs.  This  is  true  to 
the  extent  that  a given  output  can  select  any  one  of  10  inputs.  However,  the  system  is 
provided  with  20  inputs.  By  means  of  internal  jumper  wires,  each  output  can  be  switched 
between  a selected  10  of  the  20  inputs.  An  attempt  was  made  to  provide  an  output  with 
only  the  inputs  logically  required. 

Control  from  the  push-button  panels  of  the  console  requires  that  one  simply  locate  the 
row  of  buttons  corresponding  to  the  desired  output  and  press  the  button  labeled  with  the 
desired  input. 

The  switcher  control  input  requires  two  addresses  in  TTL  compatible  form.  The  x 
address  is  a complimented  4-bit  BCD  digit  (0-9)  corresponding  to  the  input  desired.  The  y 
address  is  a discrete  1 of  40  strobe  to  designate  the  output.  (Refer  to  Figure  2. 1.3. 2-5.)  The 
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tally  can  be  read  by  sensing  a BCD  x address  and  y strobe  from  the  TALLY  OUT  connector. 

2. 1.3.2. 1.3  Sync  and  Test  Signals.  Synchronizing  video  sources  in  the  video  control 
center  (Figure  2.1.3.2-7)  requires  a master  SYNC  Generator.  By  deriving  all  drivg  signals 
from  one  source,  video  signals  can  be  mixed  or  switched  at  will  without  fear  of  sync 
problems.  Tektronix  146  and  147  NTSC  SYNC  Generators  serve  this  function  for  the  video 
control  center.  A set  of  Alma  Engineering  distribution  amplifiers  are  also  present  to  boost 
the  capacity  of  the  146  and  147  output  signals. 

The  maximum  SYNC  signal  requirement  is  exemplified  by  the  IVC-150  and  IVC-92B 
color  cameras  which  utUize  COMPOSrTE  SYNC,  COMPOSITE  BLANKING,  HORIZONTAL 
DRIVE,  VERTICAL  DRIVE,  BURST  FLAG,  and  SUBCARRIER. 

COMPOSITE  SYNC  is  a signal  structured  to  contain  both  horizontal  and  vertical  sync 
information.  This  signal  is  added  to  the  video  information  and  controls  the  sweep  circuits  of 
the  video  receiver.  When  the  sync  is  present  the  video  is  referred  to  as  “COMPOSITE  video  . 
Without  SYNC  present  the  signal  is  “noncomposite  video”. 

COMPOSITE  BLANKING,  like  COMPOSITE  SYNC,  contains  both  vertical  and 
horizontal  BLANKING  information.  Since  the  purpose  of  BLANKING  is  to  blank  out  video 
information  during  the  retrace  periods,  COMPOSITE  BLANKING  is  not  used  to  control 
sweep  circuits  as  is  COMPOSITE  SYNC. 


Figure  2.1.3.2-7.  SYNC  and  test  signals. 
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HORIZONTAL  and  VERTICAL  DRIVE  signals  have  a duty  cycle  that  can  control  the 
trace  and  retrace  times  of  the  horizontal  and  vertical  sweeps  respectively.  In  the  case  of 
most  video  sources  (cameras,  etc.),  H and  V DRIVE  controls  the  sweep  circuits,  while 
COMPOSITE  SYNC  is  merely  added  to  the  output  signal.  In  the  case  of  the  TE-26  cameras, 
removing  the  COMPOSITE  SYNC  input  only  changes  the  output  from  “composite”  to 
“noncomposite”  but  does  not  disable  the  camera. 

SUBCARRIER  is  a 3.579545  MHz  signal  which  is  the  basis  for  NTSC  encoded  color 
transmission.  The  SUBCARRIER  output  from  the  SYNC  Generator  is  a highly  stable  source 
used  to  phase-lock  the  internal  oscillators  of  the  NTSC  encoders.  By  having  one  source  of 
subcarrier  phase  reference,  all  video  sources  can  be  color  synchronized  and  sweep  synchro- 
nized. 

The  video  receiver  reference  is  the  BURST  which  is  located  in  the  “back  porch”  of  the 
signal.  The  BURST  FLAG  is  a signal  which  acts  as  a gate  for  insertion  of  the  BURST  into 
the  video  signal. 

In  addition  to  the  SYNC  and  DRIVE  signals,  the  generators  also  provide  several  test 
signals.  Some  examples  are  COLOR  BARS,  CROSSHATCH,  MULTIBURST,  and  CALI- 
BRATED NOISE.  These  signals  are  primarily  used  for  calibrating,  aligning,  or  evaluating 
video  transfer  circuits  or  receivers. 

The  147  has  another  feature  in  that  it  can  insert  on  a video  signal  the  Vertical  Interval 
Reference  Signal  (VIRS).  This  signal  is  a line  of  video  occurring  during  the  vertical  blanking 
period,  which  has  a standard  LUMINANCE  AND  CHROMA  content.  After  the  VIRS  is 
added,  the  signal  may  pass  through  several  amplifiers,  distribution  systems,  or  transmitters 
and  receivers,  each  of  which  could  alter  the  signal  characteristics.  By  examining  the  VIRS  at 
the  final  destination  and  processing  the  signal  so  as  to  restore  the  VIRS  signal  to  its  standard 
characteristics,  the  remainder  of  the  signal  is  corrected  as  well.  A device  that  performs  this 
processing  is  the  Tektronix  1440. 

2.1.3.2.1.4  Monitors.  Three  general  classes  of  monitors  (Figure  2.1. 3. 2-8)  are  present  in 
the  system— MONOCHROME,  COLOR,  and  WAVEFORM.  The  color  monitors  in  the 
console  are  standard  NTSC  units  with  12-in.  screens.  The  Tektronix  650  is  a much  more 
precise  unit  than  the  other  monitors  and  is  used  for  all  critical  examination  work.  All  color 
monitors  have  a cross-pulse  feature  which  allows  viewing  of  the  SYNC  and  BLANKING 
information  normally  occurring  diiring  retrace.  It  is  thus  possible  to  examine  for  SYNC 
stability,  video  tape  alignment  and  drop  out,  or  presence  of  BURST. 
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Figurt  2.1.3.2-S.  Monitor  tyttom. 


I 
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I The  650  is  connected  or  “looped”  with  a Tektronix  520  Vectorscope  and  a 529  Wave- 

form Monitor.  Routing  a signal  to  CM4  will  also  route  the  signal  to  the  520  and  529.  The 

; 529  operates  much  as  an  oscilloscope  with  sweep  and  trigger  circuits  “tuned”  to  video  line 

and  field  rates.  In  the  line  rate  mode,  the  display  shows  lines  of  video  with  the  SYNC, 
BLANKING,  and  BURST  visible.  In  the  field  mode,  an  entire  field  of  video  is  displayed.  The 
529  Waveform  Monitor  is  also  useful  in  aligning  cameras. 

■ Waveform  examination  can  be  aided  by  using  the  input  filters  provided  on  the  529. 

FLAT  response  allows  the  entire  signal  to  pass  to  the  screen.  HIGH  PASS  essentially  passes 
only  the  subcarrier  or  CHROMA  information.  IEEE  and  LOW  PASS  are  both  low  pass 
filters,  but  the  IEEE  filter  has  a much  sharper  cutoff  and  serves  to  remove  the  CHROMA 
information,  whereas  the  LOW  PASS  filter  will  distort  the  SYNC  as  well. 

The  520  Vectorscope  is  primarily  for  use  on  NTSC  color  signals.  It  will  display  line 
information  but  not  the  SYNC  interval.  The  Y,  R,  G,  and  B buttons  select  a line  display  of 
the  separate  LUMINANCE,  RED,  GREEN,  and  BLUE  information.  The  520  does  not, 
however,  display  the  actual  subcarrier  as  the  529  does.  The  520  decodes  and  separates  the 
color  signal  before  displaying. 

The  remaining  category  of  monitors  is  the  MONOCHROME  category.  The  console  has 
several  small  monitors  which  simply  display  monochrome  video  and  have  no  features  such  as 


cross-pulse.  One  large-screen  MONOCHROME  monitor  exists  for  special  purposes.  The 
Conrac  RQA-17  is  designed  to  automatically  lock  to  any  line  rate  from  450  to  1300 
lines/frame.  It  is  wired  to  the  650/520/529  monitor  loop. 

2.1.3.2.1.5  Cameras.  The  following  cameras  (Figure  2.1. 3.2-9)  are  available  in  the  video 
system: 

1.  IVC-150B 

2.  IVC-92B 

3.  TE-1000 

4.  TE-26B 

5.  TMC-2300 

6.  Color 


SYNC  (SYNC-  SYNC.  BUNKING.  H A V.  ETC.) 


ROUTING 

SWITCHER 


REMOTE 

c 

MONO 

ecu 

TE-1000 

COLOR 


NTSC 

ENCODER 


IVC-e3S 


NTSC 

ENCODER 
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I 7.  Color 

j 8.  Color 

9.  Monochrome 

10.  High  Resolution  Monochrome 

The  IVC-150  is  a three  tube,  studio  grade,  color  camera.  It  features  a 10:1  zoom  lens 
and  remote  iris  controllable  from  the  Camera  Control  Unit  (CCU)  located  in  the  console. 
This  camera  is  useful  for  taping  demonstrations  or  for  the  generation  of  any  high  quality, 
live  color  video.  The  IVC-92B  is  another  three  tube  color  camera  which  is  dedicated  to  the 
Film  Chain  system.  In  place  of  the  iris  control  the  92B  has  a Video  Gain  control  in  the  CCU. 
Associated  with  each  of  these  cameras  is  a Vertical  Aperture  Equalizer  (VAE)  which 
processes  the  NTSC  video  and  enhances  edges  and  contours  to  give  a sharper  picture. 

The  two  cameras  output  RGB  color  video  rather  than  NTSC  encoded  video.  Therefore, 
each  camera  is  associated  with  an  NTSC  encoder.  Activating  the  power  relay  to  energize  one 
i of  the  cameras  will  also  energize  the  appropriate  encoder.  However,  the  VAE’s  must  be 

i activated  separately.  The  VAE’s  are  designed  to  pass  the  video  unaltered  if  the  unit  is  not 

, energized.  The  outputs  of  these  cameras  should  be  adjusted  using  the  529  Waveform 

Monitor. 

i 

' The  TE-1000  is  a single  tube  color  camera  which  is  more  sensitive  than  the  IVC  units 

i but  has  less  picture  quality.  The  advantages  of  the  TE-1000  are  sensitivity,  small  size,  and 

the  self-contained  design  which  allows  the  unit  to  operate  on  a standalone  basis  with  no 
requirement  for  additional  equipment  other  than  the  CCU  to  produce  NTSC  color  video. 
Supplying  the  CCU  with  SYNC  and  SUBCARRIER  will  automatically  bring  the  TE-1000 
into  lock  with  house  sync. 

The  monochrome  cameras  consist  of  several  TE-26  models.  Each  unit  has  a CCU 
available.  All  the  CCU’s  for  the  TE-26’s  are  interchangeable.  The  camera  must  be  supplied 
with  H and  V DRIVE  to  operate  and  COMPOSITE  SYNC  to  produce  “composite”  video 
output.  The  CCU  must  also  be  connected  and  the  power  switches  on  both  the  camera  and 
the  CCU  must  be  ON.  These  cameras  accept  standard  C-mount  lenses  available  from  12.5 
mm  to  75  mm  focal  lengths. 

One  of  the  TE-26  units  has  been  modified  to  be  a standalone  unit.  No  sync  or  drive  is 
required  to  operate  this  camera  but  a CCU  is  required. 

The  remaining  monochrome  type  camera  is  the  TMC-2300,  1000-line.  This  model  is  a 
.standalone  unit.  It  is  designed  to  operate  as  a totally  self-contained  camera  head  or  to 
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operate  with  a CCU  (located  in  the  console).  The  only  monitor  pn*sently  available  for 
1000-line  video  is  the  Conrac  RQA.  The  2300  has  additional  features  of  scan  reversal  and 
video  inversion.  The  2300  also  accepts  standard  C-mount  lenses. 

A set  of  neutral  density  filters  is  installed  between  the  92B  and  the  optical  multiplexer 
to  control  the  intensity  of  light  entering  the  camera.  A control  on  the  filter  unit  varies  the 
density  of  the  filters.  The  lVC-150  and  92B  each  have  an  electronic  viewfinder  in  the  form 
of  a small  monochrome  monitor  located  in  the  back  of  tire  camera. 

2.1. 3.2.1. 6 Video  Tape  System.  The  Video  Tape  System  (Figure  2.1.3.2-10)  consists  of 
two  lVC-870,  two  lVC-800  helical  scan  Video  Tape  Recorders  (VTR),  and  two  CVS-504 


EXT  INPUT 


Time  Base  Conreetors  (TBC).  One  800  is  a portable  machine  usually  divorced  from  the 
system.  This  machine  can  he  connected  using  the  VT3  input  and  output  of  the  routing 
switcher.  The  other  800  is  slated  for  use  in  a portable  console  for  taping  lectures  or 
demonstrations  physically  inconvenient  to  the  console. 

The  870’s  and  the  TBCs  operate  together  to  form  the  main  Video  Tape  System.  Inputs 
to  the  VTRs  are  controlled  by  the  VTl  and  VT2  outputs  of  the  routing  switcher.  The  TBC 
can  either  pass  the  VTR  output  unaltered  and  process  the  signal  for  time  base  stability,  or 
process  and  lock  the  signal  to  house  sync. 

To  play  back,  three  options  exist.  Unprocessed  video  can  be  viewed  without  using  the 
TBC  (monochrome  only).  The  TBC  can  be  used  to  either  process  the  signal  and  improve 
time  base  stability  and  clean  up  the  sync,  or  to  process  the  video  and  lock  the  output  to 
house  sync.  By  having  the  VTR  output  locked  to  house  sync  it  can  be  treated  as  any  other 
synchronized  video  source  and  hence  can  be  mixed  with  other  sources  using  the  production 
switchers. 

2. 1.3.2. 1.7  Special  Effects  Generators.  The  video  system  contains  two  Ball  Brothers 
Mark  VII  production  switchers  or  special  effects  generators.  Each  unit  has  two  video  inputs 
and  one  output.  The  two  inputs  may  be  combined  in  several  ways. 

Wipes  are  a method  of  switching  from  one  input  to  another  by  electronically  moving  a 
boundary  across  the  picture.  The  shape  of  the  wipe  is  selected  by  push-button  switches  and 
the  speed  and  direction  are  controlled  by  the  T-handle.  The  N-N/R  switch  causes  the  wipe 
to  occur  in  the  same  direction  regardless  of  T-handle  direction.  In  the  wipe  mode  only,  the 
wipe  selector  buttons,  T-handle,  and  N-N/R  switch  are  functional. 

The  remaining  modes  are  MIX,  MAT,  and  KEY.  MIX  refers  to  the  simultaneous  display 
of  the  two  inputs  with  the  T-handle  controlling  the  relative  intensities.  KEY  is  a mode  for 
inserting  segments  of  the  B-input  video  into  the  A-input  video.  In  the  INTERNAL  KEY 
mode  the  output  is  A-input  video  unless  the  B-input  exceeds  a luminance  level  set  by  the 
KEY  SENSE  control.  When  B exceeds  this  level,  the  output  is  switched  to  the  B-input  video 
information.  EXTERNAL  KEYING  is  similar  except  that  the  switching  from  A to  B is 
controlled  by  the  signal  on  the  EXTERNAL  KEY  input  connector. 

The  MAT  function  senses  the  B-input  in  a similar  manner  to  the  INTERN.AL  KEY 
function.  Rather  than  switching  from  the  A to  the  B input  however,  the  output  is  switched 
from  the  A-input  to  a solid  color  as  determined  by  the  HUE,  SATURATION,  and 
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lA'MlNANC'K  controls.  When  UatHl  with  the  MIX  mode  on  the  second  unit,  a slinht  tint  can 
he  add^l  to  a picture. 

The  outputs  of  the  two  production  switchers  are  desipiated  PSl  and  PS2.  Four  sections 
of  the  routin>!  switcher  control  tP.e  inputs  of  the  production  switchers. 

2.1. 3.2.2  Flying  Spot  Scanner 


The  Klyinn  Spot  Scanner  (FSS)  is  a special  video  source  system  consisting  of  several 
parts.  The  general  classifications  art':  Raster  Generator  Processor,  DefUvtion  Controller. 
Position  Controller,  Video  Detector,  and  Video  Processor. 

In  relation  to  theory  of  operation,  the  main  parts  are:  CRT  (Optics),  I'ranspart'ncy,  and 
Photomultifilier  Tube  (PMT).  The  ('RT  displays  a scan  of  the  desired  sliape  with  no 
mten.sity  modulation.  I'he  optic  system  focuses  the  CRT  scan  on  the  transparency. 

.\  PM  r is  located  behind  the  transparency  to  convert  the  instantaneous  light  intensity  to 
a vohage  waveform.  In  this  manner,  tlie  phosphor  surface  of  Uie  CRT  is  equivalent  to  the 
surface  of  the  transparency.  Thus,  scanning  the  CRT  is  equated  to  scanning  the  transpar- 
ency. The  output  of  the  PMT  is  a voltage  waveform  in  time-sync  with  the  CRT  scan. 
.Additionally,  the  optics  includeil  usually  reiluce  the  scan  size  to  increase  rt'solution.  By 
changing  the  time  synchronization  Indween  the  input  CRT  scan  and  the  photomultiplier 
tube  output,  the  appan'nt  view  of  the  transparency  can  be  changed. 

The  sweeps  for  the  CRT.  Hs.  and  Vs  are  derived  from  a Celco  (Constantine  Engineering 
Lanoratories)  raster  generator  which  accepts  H and  V DRIVE  from  the  146  SYNC  generator 
and  prtxluces  two  ramp  voltage  waveforms  equivalent  to  a 4:3  aspect  rasU'r. 

The  input  control  voltages  can  be  derived  from  two  sources.  For  manual  operation,  a set 
of  controls  is  located  near  the  Raster  Processor.  The  voltmeter  can  be  switchwl  to  monitor 
any  one  of  the  control  voltages.  Throwing  the  toggle  switch  below  a control  knob  will  revert 
control  of  that  function  to  a Digital  to  Analog  Converter  (D.AC)  driven  by  the  PDP-11 
interface.  In  this  manner,  any  combination  of  computer  and  manual  control  is  (xissible. 

2.1. 3.2.2. 1 Raster  Generator/Processor.  For  this  FSS  system,  the  desirt'd  output  is 
standard  525  60  video.  Therefore,  the  input  si'an  must  be  a set  of  waveforms  (inie-.syncetl  to 
r>25'60  rates.  Beginning  with  two  orthogonal  Hs  and  Vs  sweeps  from  a raster  generator,  the 
Raster  Generator/Proce.ssor  alters  the  sweej)  waveforms  to  achieve  the  effivt  of  a T\’  .sen.sor 
on  an  aircraft. 
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Z1.3.2.2.2.  Deflection  Controller.  The  Deflection  Controller  section  contains  the 
Deflection  Drivers,  CRT,  and  CRT  Power  Supplies.  Activating  the  main  power  control  for 
the  Video  Cabinet  will  begin  a turn-on  sequence  controlled  by  time-delay  relays.  The  order 
of  activation  is  as  follows:  Deflection  Drivers  and  PMT  Low  Voltage,  CRT  Gun  Supply, 

I PMT  High  Voltage,  CRT  High  Voltage  and  Focus.  A set  of  indicator  lights  track  the  progress 

of  the  five-minute  power-up  cycle.  If  any  of  the  scanner  door  interlock  switches  are  tripped, 
the  CRT  High  Voltage  will  not  turn  on,  and  an  indicator  will  light  showing  the  interlock 
failure.  When  the  failure  is  corrected,  the  light  will  extinguish  but  the  High  Voltage  supply 
will  not  activate  for  30  seconds. 

The  sweep  signals  from  the  Raster  Generator/Processor  provide  the  input  for  the  Deflec- 
tion Drivers.  The  driver  unit  is  a Celco  RDA-1,260  dual  axis  driver  connected  to  a Celco 
Deflection  precision  yoke.  The  RDA-1,260  is  a 60-volt,  12-amp  system  which  can  fully 
deflect  the  beam  at  a rate  of  30  KHz. 

In  magnetic  deflect]  m systems  the  current  through  the  yoke  determines  the  beam 
deflection.  A consi^nt  ' arrent  will  cause  a fixed  deflection  from  center.  The  RDA-1,260  is 
i essentially  two  high  power,  operational  amplifiers  which  convert  an  input  voltage  to  a 

' proportional  current  through  the  yoke.  The  input  voltage  waveform  is  duplicated  in  the 

output  current  waveform  on  a one  volt  equals  one  amp  basis. 

f 

2.1.3.2.2.3  Cathode  Ray  Tube  (CRT)  System.  (Figure  2.1.3.2-11.)  The  CRT  is  a seven- 
in.,  flat  screen,  42°  deflection  tube  with  a 1.5  mil  minimum  spot. 

The  light  from  the  CRT  is  focused  by  mirrors  and  lenses  onto  the  surface  of  the 
transparencies.  Two  20  x 20  in.  glass  transparencies  are  mounted  in  a single  carrier  frame. 
The  light  from  the  CRT  is  split  into  two  beams  such  that  the  two  transparencies  are  scanned 
in  parallel.  A photomultiplier  tube  for  each  plate  is  located  on  the  opposite  side  from  the 
CRT  and  optics.  The  carrier  frame  is  positioned  by  a set  of  X-Y  servos. 

The  CRT  is  driven  by  the  CRT  Gun  Supply  and  High  Voltage  Supply  located  in  the 
Video  Cabinet.  The  Gun  Supply  is  a Litton  model  1050  which  supplies  the  filament  and  grid 
voltages  to  the  CRT. 

The  1050  Gun  Supply  also  has  a CRT  intensity  modulator.  The  modulator  circuit  board 
has  been  removed  from  the  1050  chassis  and  mounted  adjacent  to  the  CRT  in  the  Scanner 
Cabinet. 
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X-Y  SCOPE 


VIDEO  PROCESSOR 

RASTER  GENERATOR/PROCESSOR 

PDP-11  INTERFACE 


Tho  miKhilntor  is  drivoH  by  Un?  Vidt'o  I’rocossor  to  blank  Iho  CUT  diirinii  rotnu'o  and 
poriods  oorrospondinn  to  horizon  and  sky  of  Uu'  (ji'HoratiHl  srono.  Tbo  diMails  of  Uiis  oinniil 
art'  oxplainixl  in  the  sootion  on  the  Vidro  Prooessor. 

'rbo  focus  supply  is  a bitlon  1008  for  mattuotic  focus  systems.  I'lic  focus  coil  is  mount ihI 
U'hind  the  deflection  yoke  on  the  CRT.  The  focus  control  is  locatwl  on  Uie  1008  in  the 
Vkleo  ('abinel.  The  llinh  Voltnjte  supply  is  a S|>ellman  .10  kv  svipply.  The  normal 

settiuK  for  this  system  is  27  kv.  Since  the  Rd-IO  is  a vacuum  lube  supply,  appn)ximalely  15 
secotuls  is  requinxl  for  warm-up.  The  final  sequence  rt'lay  activates  both  the  1008  and  the 
R(i-.10.  Roth  suppli(>s  drop  out  if  a door  interlock  switch  is  trippixl.  Normally  these  supplies 
are  m)t  adjustinl  during  operation. 

2.1.3.2.2.4  Video  Detector.  The  photomultiplier  tubes  nupiire  *7.5  volts  and  -000 
volts.  A Kepco  supply  located  in  the  Vi«leo  ('abinet  provides  the  000  volts.  This  supply  is 
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I stHjuenitHl  on  just  prior  to  tho  ('R  T llinl'  Voltum*.  powor  to  this  supply  also  «'norKiz»‘s 

1 tlu*  door  interlock  indicator.  Mcncc.  a lock  failure  will  not  .show  la'forc  tlic  I’M  l'  .supply  is 

aciivaUxl.  'I'hc  +7.5  volt  supply  is  Uu'atcd  in  the  .s<'anncr  t'ahinct  ladwccn  the  two  I’NlT’s 
hchind  the  transparency.  This  supply  is  activatinl  with  the  main  power  breaker. 

I 

The  PMT  assembly  consists  a PM  tube  and  an  integrated  amplifier,  Imth  houstnl  in  a 
metal  cylinder.  The  amplifier  s»*rves  to  boost  Uio  PMT  output  voltage  aiul  to  retluce  out|>ut 
impetlaitce.  By  having  the  ami>lifier  in  the  same  housing  as  the  PM'!',  noise  pickup  is 
rtHlucwl.  Kach  PMT  as.sembly  is  suppliwl  + 7.5  volts  and  -900  volts  (BN(')  atul  outputs  a 
ont‘-volt  P-P  signal  to  a TN('  ci>nnoctor.  This  output  drives  the  Valeo  Processor  cin'uitr>’. 

! Kxcept  for  a common  ground,  no  ehn'trical  conntH'tions  exist  between  the  PM'P  system  and 

t the  CRT  or  Deflection  systems.  The  only  coupling  is  the  light  passing  from  the  CRT  through 

I the  transparency  to  the  PMT. 

2.1. 3.2.2. 5 Position  Controller.  The  rtmiaining  st'ction  of  the  Scanner  Cabinet  is  a 

I fetxlback  Servo  System.  Sptanl  feetlback  (see  Figure  2.1.0.2-12)  is  im|)lement(Hl  in  the 

I following  manner.  The  ovitput  of  the  two  motors  runs  into  a diffenmtial  gear.  By  adj+isting 

( the  sp(>«*d  of  each  motor,  the  output  of  the  differential  can  Ih»  set  to  a nonrotation 

■ condition.  This  continuous  running  of  tlie  motors  nnluces  the  inititU  startup  delay  i>f  the 

servos.  When  the  course  position  gets  within  a certain  window  the  analog  switch  changes  the 

i 

motor  sptH'd  contn>l  from  coarse  control  to  fine  control. 

The  prt'.sent  system  is  interfactnl  through  digital  to  analog  converters  to  the  PDP-l  1. 

2.1.3.2.2.6  Video  Processor.  The  output  from  the  photomultiplier  tulw  system  is  a 
raw  video  signal  with  no  SYNC,  BLANKlNtl,  or  black  refenmee  level.  The  Viileo  I'roces.sor 
si'ction  contains  the  circuitry  to  clean  up  the  video  and  adil  the  luvessarj'  SYNC  aiul  some 
special  effects.  (Refer  to  Figure  2.1.3.2-13.) 

The  Proc  Amp  circuitry  receives  the  raw  video  from  the  PMT  and  (lerforms  the  follow- 
ing functions.  The  signal  is  keyclamptnl  ami  limited  to  proiluci>  a uniform  amplitude, 

uni|iolar  signal,  mivting  "video  information"  signal  sprvifications.  The  Proc  .\m(i  then  ! 

blanks  the  signal  and  inserts  SYNC  us  requirwl.  BURST  is  also  insertinl  in  the  "back  (Hin'li".  j 

As  .shown  in  Figun'  2.1.3.2-13,  the  Proc  Amp  uses  signals  from  tlie  Tektronix  l l(»  to 
j (lerform  these  tasks.  The  output  fnnn  the  Proc  Anqi  is  a standanl  NTSC'  video  signal. 

I In  addition  to  the  above  tusks  the  Proc  Am()  has  the  feature  of  adding  a CIIROM.V  .signal 

to  the  vulix).  This  CHROMA  signal  is  generateil  by  the  llori/on  Simulator. 
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Figure  2.1.3.2-13.  Video  Processor. 
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The  Horizon  Simulator  consists  of  four  parts— BURST  and  CHROMA  phase  controller, 
threshold  detector,  CHROMA  modulator,  and  CRT  modulator. 

The  phase  controller  produces  2 3.58  MHz  signals  with  independent  phase  controls.  The 
BURST  controls  the  phase  of  the  BURST  on  the  video  output  relative  to  master  phase  from 
the  146.  In  this  manner,  compensation  can  be  made  for  the  phase  shifts  caused  by 
propagation  delays.  The  CHROMA  SUBCARRIER  phase  control  determines  the  HUE  of  the 
CHROMA  generated  by  the  CHROMA  modulator. 

The  CHROMA  modulator  receives  a signal  from  the  threshold  detector  and  outputs  a 
CHROMA  signal  controlled  in  HUE  by  the  phase  controller  and  adjustable  in  SATURA- 
TION and  LUMINANCE  by  separate  controls.  By  using  the  three  controls  the  inserted  sky 
can  be  set  to  any  color  within  NTSC  capabilities.  The  intensity  of  the  inserted  CHROMA  is 
also  modulated  by  the  threshold  detector  to  produce  a smooth  transition  from  ground  to 
sky. 

The  threshold  detector  performs  several  functions.  The  mathematical  equivalent  of  a 
sensor  looking  at  the  horizon  is,  for  some  terms,  going  to  infinity.  The  scan  signals  from  the 
Raster  Processor  are  level  detected  to  determine  the  occurrence  of  the  infinity  terms.  Upon 
detecting  an  infinity  condition,  the  threshold  detector  outputs  two  signals.  One  signal  drives 
the  CHROMA  modulator  and  “turns  on”  the  sky  while  the  other  signal  simultaneously 
i blanks  the  CRT  and  eliminates  the  video  information  from  the  PMT’s.  The  output  from  the 

[ threshold  detector  is  not  a binary  signal  but  is  a fast  ramp  designed  to  give  a “soft” 

I appearance  to  the  horizon.  The  “threshold.’  and  “horizon  gain”  controls  adjust  the 

I detection  point  and  output  signal  slope  respectively. 

I Since  the  threshold  detector  outputs  a signal  capable  of  blanking  the  CRT,  the  com- 

; posite  BLANKING  signal  from  the  146  is  supplied  to  the  circuitry  to  blank  the  raster  during 

retrace.  Similarly,  a crosshatch  signal  can  be  applied  to  the  raster  for  test  purposes. 

! The  raw  video  at  the  output  of  the  PMT  contains  no  synchronization  information.  A 

[ monitor  could  not  operate  on  the  PMT  output  alone.  The  sync  signals  added  by  the  Proc 

I Amp  provide  the  necessary  timing  information.  The  raster  which  produces  the  light  input  to 

[ the  PMT  is  timed  by  only  the  H and  V DRIVE  pulses  supplied  to  the  raster  generator 

circuitry.  Since  the  SYNC  added  by  the  Proc  Amp  and  the  H and  V DRIVE  used  by  the 
raster  generator  are  from  the  same  source,  the  PMT  video  will  be  properly  timed,  relative  to 
the  added  SYNC.  If,  however,  the  H and  V DRIVE  signals  are  phase  shifted  relative  to 
SYNC,  the  raster  will  be  late  in  starting  a scan.  Since  a display  monitor  begins  a scan 
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according  to  the  SYNC,  a time  lag  will  be  created  between  the  raster  and  the  display.  This 
“time”  lag  will  cause  a “position”  shift  to  occur  in  the  video  information  as  displayed  on 
the  monitor.  Thus,  delaying  the  H and  V DRIVE  has  the  effect  of  moving  the  picture  down 
or  to  the  side  on  the  display. 

As  far  as  the  simulation  is  concerned,  the  moving  of  the  picture  down  is  equivalent  to 
pitching  the  aircraft  up  toward  the  sky.  The  raster  delay  circuitry  performs  this  task,  and 
the  delays  are  continuously  variable  and  may  be  set  by  computer  control.  The  delay 
circuitry  also  generates  a signal  during  the  period  between  the  input  drive  pulse  adn  the 
delayed  output  pulse  to  drive  the  horizon  simulator  and  turn  on  the  sky.  In  this  manner  the 
picture  “wrap-around”  is  eliminated.  A control  line  on  the  horizon  simulator  inverts  the 
signal  from  the  delay  circuits,  resulting  in  a sense  of  moving  the  picture  up,  rather  than 
down.  This  discussion  made  reference  only  to  vertical  delays  and  movements;  however, 
similar  circuitry  exists  for  the  horizontal  channel  and  results  in  left  or  right  movements.  The 
manual  and  digital-to-analog  converter  controls  are  channel  independent. 

2.1.3.2.2.7  PDP-11  Interface.  The  PDP-11  interface  driving  the  Video  System  and  the 
Flying  Spot  Scanner  is  based  on  a circuit  designed  for  the  DAIS  Hot  Bench.  The  interface 
built  for  the  Video  Center  is  for  data  output  only  with  no  provisions  for  input  data  from  the 
Video  Center  to  the  computer.  Furthermore,  the  Video  Center  accepts  digital  data,  hence 
no  synchro  or  resolver  conversion  is  required. 

2.1.3.2.2.8  Interface  Software.  The  purpose  of  the  interface  control  software  is  to 
initiate  block  transfer  of  data  from  the  computer  memory  by  providing  the  necessary 
commands  to  the  DRll-B.  The  block  transfer  is  initiated  when  the  interface  control 
software  loads  the  word  count  register  with  the  2’s  complement  of  the  number  of  words  to 
be  transferred,  specifies  the  initial  address  of  the  memory  block  where  the  transfer  is  to  be 
made,  selects  the  interface  to  receive  the  block  transfer,  appropriately  setting  bits  2 and  3 
(function  2 and  function  3)  of  the  command/status  register,  and  issues  a GO  pulse  by 
loading  bit  0 of  the  command/status  register. 

As  the  transfer  is  taking  place,  the  control  software  monitors  bit  7 (the  ready  bit)  of  the 
command/status  register.  Detection  of  a 1 in  the  ready  bit  indicates  the  completion  of  the 
block  transfer. 

2.1.3.2.2.9  Scanner  Video  Control.  The  Raster  Generator/Processor  is  controlled  by 
DC  voltage  inputs.  These  voltages  are  supplied  from  seven  DAC  cards.  Each  DAC  card 
contains  two  sections  of  eight  bits  each  (two  BCD  digits)  and  a polarity  controller.  The 
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output  voltage  range  is  from  -9.999  volts  to  +9.999  volts.  To  transfer  data,  a buffer  is  sei  -p 
with  the  14  words.  The  lower  eight  bits  of  a word  must  form  the  bit  pattern  corresponding 
to  the  two  BCD  digits  to  be  transferred.  The  ninth  bit  of  a word  is  the  sign  bit  with  “0”=+ 
and  “1”=-. 


Table  2.1. 3. 2-3  indicates  the  control  function  of  each  DAC. 


The  following  is  a description  of  the  control  functions  with  appropriate  limits: 


1.  The  size  controller  corresponds  to  slant  range  or  altitude  (limits  +1500  to  +9999); 

2.  Heading  is  the  compass  heading  with  +5000  equal  to  North,  (limits  -9999  to  +9999); 

3.  Roll  changes  the  perspective  look  angle  about  the  roll  axis;  +5000  is  straight  down; 
below  5000  is  left  and  above  5000  is  right  (limits  +500  to  +9000); 

4.  FOV  or  field-of-view  simulates  various  sensor  fields-of-view  and  is  limited  by 
approximation  to  ±25° ; exact  calibration  is  subjective,  but  a good  guess  is  that  25°  is 
+4000;  therefore,  the  limits  are  +0  to  +4000. 

5.  Forward  depression  or  pitch  is  similar  to  roll  except  about  the  pitch  axis;  +5000  is 
straight  down  with  +400  to  +5000  corresponding  to  a forward  look  angle  (limits 
+400  to  +9200); 

6.  The  delay  control  DAC’s  are  wired  to  output  only  positive  voltages;  the  sign  bit  has 
been  wired  to  the  “invert”  line  of  the  “raster  delay”  circuits. 

2.1.3.2.2.10  Switcher  Control.  The  Routing  Switcher  may  be  controlled  by  the  PDP-11 
through  the  interface.  The  lower  six  bits  of  the  lower  bits  are  the  binary  number  of  the  y 
address.  The  lower  four  bits  of  the  upper  bits  is  the  x address.  By  creating  a word  in 
memory  with  the  appropriate  bits  set,  the  switcher  can  be  commanded  from  the  computer. 


TABLE  2.1.12-3.  OAC  CONTROL  FUNCTIONS 


Data  Word 

Data  Saction 

Output 

Data  Word 

Data  Saction 

Output 

1 

1A 

8 

4B 

FOV 

2 

IB 

Siza 

9 

5A 

3 

2A 

10 

SB 

Pitch 

4 

2B 

Heading 

11 

6A 

5 

3A 

12 

6B 

Vertical  delay 

6 

3e 

Roll 

13 

7A 

7 

4A 

14 

7B 

Horizontal  delay 
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2.1. 3.2.3  Summary 


The  purpose  of  the  Video  Control  Center  is  the  control  and  generation  of  video  signals 
for  the  simulation  laboratory.  The  routing  of  video  is  by  solid-state  switching  and  can  be 
controlled  by  computer.  Circuitry  for  video  generation  by  the  Flying  Spot  Scanner  is  also 
under  computer  control.  Steps  were  taken  to  provide  similar  control  for  the  video  tape 
system.  All  systems  are  also  provided  with  manual  controls.  The  capability  also  exists  for 
video  &om  film. 

Monitors  are  available  to  view  all  video  signals  passing  through  the  system.  Additionally, 
test  signals  and  monitoring  eqi  'pment  are  available  to  evaluate  the  quality  of  the  video 
signals. 

2. 1.3.3  Cockpit 

2.1. 3.3.1  Introduction 

A two  place,  side-by-side  cockpit  simulator  of  F-111  dimensions  was  fabricated  as  a 
multipurpose  test  bed  to  evaluate  controls  and  displays  integrated  with  the  overall  avionics 
systems  as  shown  in  Figure  2.1. 3.3-1.  The  complete  computer  simulation  includes  the 
cockpit  with  controls  and  displays  wired  to  the  other  elements  of  the  system  in  terms  of 
hardware  or  simulation  models,  with  the  cockpit  rigged  for  realistic  flight  simulation. 
Man-machine  interfaces  are  also  evaluated  in  the  realistic  flight  environment,  using  outside 
visual  cues  related  to  the  missions.  These  efforts  are  centered  around  the  engineering 
problems  involved  in  integrating  the  sensors,  processors,  and  displays/controls  in  the  digital 
aircraft,  and  the  human  factor  problems  involved  in  piloting  this  aircraft.  Another  issue  to 
be  considered  is  redundancy  and  failure  analysis. 

Control  and  display  equipment  can  be  arranged  to  include  a Head-up  Display  (HUD), 
Horizontal  Situation  Display  (HSD),  Vertical  Situation  Display  (VSD),  Multi-purpose 
Displays  (MPD’s),  Control  Panels,  Multi-function  Keyboards  (MFK’s),  etc.  The  total  cockpit 
configuration  can  be  rapidly  and  easily  changed  to  suit  a particular  equipment  functional 
evaluation. 

2.1. 3.3.2  Simulator  facilities 

The  cockpit  simulator  functions  in  an  interconnection  of  AVSAIL  facilities  as  shown  in 
Figure  2.1. 3.3-2.  A brief  functional  de.st?ription  of  each  system  element  is  providwl  in  the 
following  .section.s. 
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2.1.3.3.2.1  DECsystem  10.  The  DEC-10  host  processor  is  connected  as  the  primary 
system  controller  and  provides,  on  a time-shared  basis,  the  following  functions  as  related  to 
operation  of  the  cockpit: 


1. 


Simulation  Models;  — provides  all  necessary  aircraft  parameters  to  the  11/45  to  be  used  in 
display  processing; 

Map  .Assembly:  — generates  a display  list  of  symbolic  waypoint  map  information  to  be 

processed  by  the  Ramtek  symbol  generator; 

Data  Recording:  — records  cockpit  display  parameter  data  on  magnetic  tape  at  a 20  s 

iteration  rate; 

Data  Reduction:  — an  off-line  program  reduces  the  raw  real-time  rec(>rded  data  into 

meaningful  data  that  ciui  be  analyzed. 


MO 


2.1.3.3.2.2  PDP  11/45  Computer  Interface.  This  general  purpose  digital  computer  pro- 
vides the  following  functions: 


r 


1.  Configuration  Control  — used  to  set  up  the  cockpit  controls/displays  configuration 
prior  to  each  flight; 

2.  Display  Assembly  — generates  image  listings  to  be  further  processed  by  the  Ramtek 
raster  symbol  generator;  data  from  the  simulation  models  was  used  for  the  VSD  and 
MPD  formats. 

3.  Map  Driver  — provides  output  control  of  map  data  to  the  Ramtek  symbol  generator; 
the  image  lists  of  the  map  are  done  by  the  DEC  10; 

4.  Keyboard  Logic  — processes  incoming  switch  data  .md  determines  the  display  state 
of  all  the  keyboards; 

5.  Flight  Control  Sampling  and  Scaling  — buffers  and  scales  flight  control  data  to  be 
list'd  by  the  DEC-10  simulation  models. 

2.1.3.3.2.3  Out-The-Window  Display.  In  order  to  present  a more  realistic  environment 
to  the  pilot  when  the  cockpit  simulator  is  lieing  used  for  man-in-the-loop  experimentation,  a 
large-scale  parabolic  projector  scrt'en  is  mounted  forward  of  the  cockpit.  The  display 
information  is  projectwl  onto  the  screen  by  video  projectors  driven  from  the  Video  Control 
Center.  This  display  presents  a moving  real-time  scene  which  changes  in  response  to  the 
pilot's  control  actions  to  the  cockpit  controls. 

2.1.3.3.2.4  Ramtek  Display  Generators.  These  generators  drive  525  line  raster  monitors 
in  the  cockpit  in  response  to  processed  image  lists  and  provide  the  vertical  and  horizontal 
situation  displays  described  subsequently. 

2.1.3.3.2.5  Cockpit  Functional  Hardware.  The  cockpit  layout  as  shown  in  Figure 
2. 1.3. 3-1  is  arranged  with  the  pilot  seated  in  the  right  side  of  the  cockpit  while  the  left  seat 
is  occupied  by  an  experimenter.  The  controls  and  displays  for  the  left  seat  may  or  may  not 
be  activated.  As  the  cockpit  is  considered  a general  purpose  test  facility,  a large  variety  of 
test  configurations  are  possible.  The  basic  elements  of  the  cockpit  functional  capability  are 
described  below. 


Provided  as  part  of  the  cockpit  is  a Keyboard  Input/Output  interface  which  stores  a 
switch  image  buffer  of  all  cockpit  switch  states  to  be  sampled  by  the  11/45.  .Mso  decoded 
are  keyboard  lamp  data  which  are  sent  from  the  11/45  to  the  cockpit  to  selectively  turn 
lights  on  or  off.  The  keyboard  input/output  interface  provides  the  capability  of  sampling 
and  storing  the  states  of  255  switches  and  driving  255  lamps.  A similar  Flight  Control 
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function  is  provided  which  digitizes  analog  stick,  rudder,  and  thrust  control  inputs  and 
buffers  the  resultant  data  for  transmission  to  the  11/45  computer. 


Four  electro-optical  displays  are  available  to  provide  information  for  utilization  by  the 
Vertical  Situation  Display  (VSD).  Figure  2. 1.3. 3-3  depicts  a typical  VSD  format.  A nine-in. 
diagonal  color  display  presenting  the  following  symbology  consisting  of:  (1)  an  orange 
horizon  line  delineating  the  boundary  Ijetween  a blue  sky  and  brown  earth  background,  (2) 
a white  pitch  ladder  with  5 and  10  degree  pitch  lines,  (3)  black  roll  indexes  ever>’  ten 
degrees  (±  60  degrees)  with  a white  roll  index  marker,  (4)  a flight  director  symbol  in  orange, 
and  (5)  a fixed  black  aircraft  symbol.  Altitude,  indicated  airspeed,  heading,  vertical  velocity, 
and  acceleration  (g’s)  are  presented  digitally  in  white  on  black  background.  In  addition, 
trend  information  for  the  airspeed  and  altitude  parameters  is  provided  by  white 
thermometer  type  bars  which  are  placed  above  the  respective  digital  readouts. 


i 
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A nine-in.  diagonal  color  monitor  presents  simplified  navigation  information  for  the 
Horizontal  Situation  Display  (HSD)  in  the  form  of  an  electronic  map  in  a heading-up  or 
north-up  format.  The  symbology  consists  of:  (1)  a triangular  aircraft  symbol,  (2)  a 
symbolic  flight  path  between  mission  waypoints,  and  (3)  digital  readouts  of  ground  speed 
heading,  and  distance  to  the  next  waypoint.  All  symbology  is  green  on  a black  background. 
Figure  2.1. 3.3-4  depicts  a typical  Horizontal  Situation  Display  format. 


Two  five-in.  diagonal  monochrome  monitors  are  used  for  Multipurpose  Displays 
(MPD’s).  The  one  mounted  on  the  left  side  of  the  cockpit  provides  either  communication 


Waypoint 

Position 

Identifiers 


Figurt  2.1. 3.3-4.  Typicil  Horizontal  Situation  Display  (HSD)  format. 
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data  or  navigation  data.  Engine  instrumentation  and  keyboard  failure  status  information  are 
displayed  on  the  right  MPD.  This  MPD  has  sixteen  peripheral  push  button  switches  which 
are  available  for  general  use.  Each  monochrome  monitor’s  presentation  is  typically 
formatted  in  a conventional  text  mode,  however  this  is  not  a requirement. 

The  console’s  four,  six-in.  diagonal,  monochrome  CRT  displays  provide  the 
experimenter  with  an  experimental  console  for  monitoring  the  simulator  displays  (VSD, 
HSD,  and  2 MPDs).  The  experimenter  is  also  able  to  initiate  tasks  and  control  the 
normal/failure  status  of  the  configurations.  In  order  to  minimize  experimenter  workload, 
cockpit  reconfiguration  is  automated  as  much  as  possible  and  incorrect  waypoint  and 
frequency  digits  are  detected  by  the  computer. 

2.1. 3.3.3  An  example  test  configuration 

Of  the  many  keyboard  configurations  possible,  one  which  has  been  evaluated  repeatedly 
employs  multifunction  keyboards  (MFKs).  A typical  cockpit  evaluation  employed  two 
types  of  MFKs  and  one  dedicated  keyboard. 

One  MFK  consisted  of  16  push-button  projection  switches.  Each  switch  had  12  possible 
It'gends.  The  legends  were  programmed  to  inform  the  pilot  of  the  four  levels  of  systems 
control  available. 

The  other  MFK  utilized  a plasma  panel  with  16  peripheral  push-button  switches.  Each 
switch  was  associated  with  a legend  located  on  the  plasma  panel.  Due  to  the  relative 
difference  in  sizes  of  the  .switches  and  plasma  panel,  the  legends  were  not  directly  adjacent 
and  in  line  with  the  corresponding  switches.  Therefore,  each  switch  was  associated  with  the 
appropriate  legend  by  a white  line.  The  switches  were  operable  only  when  information  was 
displayed  adjacent  to  the  switches  on  the  plasma  panel.  The  plasma  panel  MFK  and 
projection  switches  MFK  were  functionally  redundant. 

The  digit /mode  panel  consisted  of  17  dedicated  push-button  switches.  Twelve  of  the 
keys  served  as  a data  entry  panel;  five  served  as  mode  .select  keys.  The  five  switches  were 
backlighted  to  indicate  mode  selected  (green-selected,  white-not  selected). 

The  dedicated  digit/niode  panel  was  mounted  forwarxl  of  the  throttle.  Each  type  of 
MFK  was  mounted  on  the  front  panel  during  half  of  the  flights  and  on  the  right  hand 
console  during  the  other  flights.  Thus,  the  operation  of  each  MFK  type,  both  as  a primar>’ 
(front  instrument  panel)  keyboard  and  as  a backup  (right  console)  keyboartl.  could  be 
examined. 
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At  tho  initialization  of  oaoli  tost  flight,  tin*  displays  won*  in  tin*  following 
oinifiRnnUion:  (a)  VSD  Fli({l>t  parann'tnrs  won*  appropriaU*  to  that  of  lovol  fli(dit  in  a 

t 

I I’niiso  modo  with  an  aititndt*  of  20,000  fwt  and  indicaltKl  airsptH'd  of  001  knots:  (h) 

HSI>-Airoraft  position  was  approximaU’ly  7 milos  short  of  waypoint  1;  tin*  hnadini:  was  tin* 
S4>nn'  as  that  for  tin*  first  !«*({■  Tin*  ipronnd  sptHHl  was  001  knots;  (r)  Loft  Ml’D  KnKino  status 
format  was  display«xl;  (d)  Ri^ht  Ml’l)  -Knjjiin*  status  format  was  display^!.  Tin*  SKNSORS 
inodo  at  lo(iio  lovol  1 had  ho<’n  aotivat«'<i  on  tin*  appropriate*  koyl)«>anl. 

rhn>UKln>ut  oaoh  flight,  tin*  inf<»rmatk)ti  displays!  on  tin*  VSI)  and  IIS!)  was  dynamic  in 
’ n*spe>nst*  to  thnist.  hank,  and  pitoh  inputs.  Howovor.  tho  flight  ilirootor  ten  tho  VSD  was 

inoporahlo  until  Un*  pilot  orosswl  waypoint  1.  SoUvtion  of  t'DMM  or  NAV  on  tin* 
appttipriaU*  koyhoeu'd  dotormiirixl  wln*thor  oommunioation  or  navication  status  was 
elisptayi*d  on  tin*  loft  Ml’l).  Whon  displaywl,  tho  navination  status  on  tho  loft  Ml’l) 
oonstantly  pros<*nUHl  now  information  such  as  aircraft  position,  timo,  disUuK’o  to  tin*  noxt 
waypoint,  oto.  Alse*.  tin*  oommunioation  fe)rmat  display  prosontod  tho  status  of  tho 
oe)mmunie*ation  radios. 

j I'ho  appropriate*  ki*ytnnmls  won*  inoporativo  until  aotivattHl  hy  tin*  oxporimontor. 

Activation  e)f  tho  following  switohos  was  n*quirod  for  a naviKation  updato;  NAV,  NAV 
(X)M1’,  VVAYl’'!’,  ainl  tho  appropriato  dinits.  If  an  incorrect  switch  was  pushed  in  levels  1.  2. 

I <ir  .’1.  lonoiuls  unrolali*<l  te»  tho  n’<|U0.ste*<l  task  appounxl  on  tin*  koyhoanl.  In  order  to 

j comploto  tho  n*quir»xl  task,  tho  pih)t  hatl  to  corn*ct  tho  mistake.  To  accomplish  this,  tin* 

piU)t  puslnxl  tho  CLKAR  swiU'h  onci*  to  n*turn  tho  koyhoanl  to  tho  pn*vii>us  lovol  and  then 
made  Un*  proper  soUvtion.  Once  tho  pilot  machod  tho  feeurth  Ionic  lovol  st«*p,  a pn*-ontr>' 
readout  e>f  each  .solivtixl  dijfit  was  availahio  on  tho  navination  Ml’l)  formal.  Whon  tho  pilot 
puslnxl  tin*  KN'l’KR  hutton,  the  computer  inh*rpn*to»l  the  dinits  soloctod  aiul  dotormiinxl 
their  ae  curacy.  If  tin*  pilot  luul  puslnxl  an  inci>rrocl  elinit.  tho  error  mossano,  ‘‘IN('ORRK(''r 
DKil'l'  KN'l’RY,  RK-KN’rKR,"  was  prose*ntexl  at  tho  le)p  of  tin*  display  atnl  the  pilot  would 
ro-ontor  tho  oornx’t  data.  Once  tho  daU»  wascorrwtly  onton*d,  tho  task  would  ho  comploto; 
tin*  keyboard  woidd  reinitialize  to  lonio  level  enie  ami  then  heceenn*  doactivateil. 

For  a comnuinicalion  channe,  activation  of  the  followinn  switches  was 
nxpiirexl:  (’OMM,  UHF  and  IHIF  I’OWF.R,  A/N  and  appropriate  dinits.  Both  I'llF  and  UllF 
I’OWF.R  switches  wi*n*  selocUxl  at  step  2.  llowe*ver,  durinn  the  seceenil  communication 
! channe  of  oaoh  flinht.  tho  IdlF  power  n*maiinxl  active  so  that  the  r»xjuin*d  switi  h .s«xpionco 

I Ixx'ame:  (’OMM,  UllF,  A/N.  and  its  ilinits.  Tho  Ml’D/koyhoanl  channos  and  rolattxl 

proc«xhm*s  of  a communication  channe  won*  similar  to  that  of  a navination  updato. 
Howovor,  if  a pilot  onlon*d  an  incorrect  fnxjuoncy  that  was  still  '.vithin  tho  normal  UllF 
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froquonoy  run>;e.  the  koyboiird  roturnod  to  the  thiixl  level,  hut  no  error  inessatje  was 
presented  on  tl\e  MPl).  The  pilot  was  then  notified  by  the  experimenter  to  redo  the  task. 

t'oneerninn  the  normal /failure  status  of  the  confi^juration,  each  flight  was  initialized  m a 
normal  mode.  Wlien  the  experimenter  changed  the  configuration  to  a degraded  mode,  the 
master  caution  light,  located  to  the  left  of  the  VSD,  flashed  orange.  When  the  pilot 
acknowletiged  the  failed  slate  by  pushing  tlu>  master  caution  light  the  flashing  stopped, 
t'oncurrently,  a primary'  keyboani  became  inoperable  anil  tlie  logic  levels  that  were  on  the 
keyboiuxl  were  presenU'd  on  the  right  console  keyboani.  When  a failure  occurred,  the 
display  on  the  right  MPL)  was  replaced  with  the  failun'  message.  This  format  specified  which 
keyboani  was  failed  and  the  logic  levels  that  were  operable  on  the  right  console,  backup 
keyboani.  When  the  experimenter  returned  the  cockpit  to  a normal  mode,  the  master 
caution  light  Hashed  green,  the  primary  keyboani  became  operable,  the  right  console 
keyboard  became  inoperable,  and  the  information  displayed  on  the  right  MPD  indicated 
that  normal  operation  was  reinstated. 

Cither  controls  used  included:  (a)  flight  mode  select  panel— only  the  cruise  mode  was 
utilized  in  this  study;  (bl  landing  gear  control  panel— speed  brakes  and  flaps  were 
operational  while  landing  gear  was  not;  and  (c)  pitch  indication  zeroing  switch- -activation  of 
this  blue-lighted  push-button  switch  aligned  the  horizon  line  with  the  aircraft  symbol  at  that 
pitch  altitude. 

Thrust  was  controlleil  by  a left-side,  slide  control  throttle.  Bank  and  pitch  commands 
were  input  either  by  means  of  a center  stick  mounted  on  tlie  floor  ora  side  stick  mounted 
on  the  right  console.  This  latter  configuration  also  had  a right  side  armrest. 

2.1.3.3.4  Future  development 

Proposed  additions  to  tlie  cockpit  facility  include  u Head-up  Display  and  a Helmet 
Mounteil  Display.  The  intent  of  these  displays  will  be  to  present  well  concentrated  flight 
data  to  the  pilot  in  order  that  it  will  no  longer  be  nece.s,sary  to  observe  continuously  a 
number  of  display  panels.  Instead,  the  pilot  can  concentrate  on  one  or  perhaps  two  displays 
mounteil  directly  in  front  of  him  and  thereby  lx*  able  to  fly  at  all  times  in  a “head-up” 
mode. 
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2.2  AVIONICS  EVALUATION  PROGRAMS 

The  Avionics  Evaluation  Program  (AEP)  is  a collection  of  avionic  performance 
assessment  models.  The  AEP  provides  convenient  and  systematic  assessment  of  avionics  in 
the  mission  environment.  The  program  is  designed  to  be  flexible  and  easy  to  use  with 
emphasis  on  realistic  consideration  of  the  operational  environment  and  the  generation  of 
useful  data.  AEP  can  be  utilized  for  analysis  of  most  air-to-ground  and  air-to-air  missions. 
Individual  programs  contained  within  AEP  include  air-to-ground  and  air-to-air  mission 
analysis,  weapon  delivery  error  analysis,  target  acquisition  analysis,  and  a one-on-one 
dogfight  analysis.  These  programs  are  implemented  in  a conversational  interactive  mode  thus 
providing  a powerful  analytical  tool.  These  programs  are  available  to  users  by  means  of 
dial-up  terminals  and  therefore  are  available  throughout  DOD  as  well  as  contractor 
organizations. 

2.2.1  AEP  Program  Capability 

2.2.1. 1 Air-to-Ground  Mission  Analysis  Programs 

The  air-to-ground  mission  analysis  program  evaluates  the  performance  of  a flight  of  up 
to  four  aircraft  through  a specified  number  of  days  of  operation.  The  aircraft  proceeds  along 
an  externally  generated  nominal  trajectory  through  the  mission  phases  of  takeoff,  navigation 
to  the  search  area,  search,  attack,  and  return  to  base.  Consideration  of  ground  service 
requirements  is  included.  Monte  Carlo  techniques  are  applitnl  to  MTBF  (Mean  Time 
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Between  Failure)  data  for  the  defined  avionics  throughout  the  mission  to  determine  which 
subsystem  modes  are  functioning,  resorting  to  backup  modes  and  mission  aborts  as  required. 
The  model  utilizes  the  best  mode  still  available  for  each  function  at  the  time  it  is  to  be 
performed.  Target  location  uncertainties  and  navigation  system  performance  parameters  are 
combined  to  define  the  actual  flight  path,  relative  to  the  true  target  location.  The  sensor 
ground  swatch  for  the  defined  search  pattern  is  then  compared  to  the  true  target  location  to 
determine  if  the  target  passes  through  the  sensor  ground  area  coverage.  Probabilities  of 
detection,  target  kill,  and  aircraft  survival  are  sampled  to  determine  which  mission  phases 
are  successfully  completed. 

The  following  steps  are  required  to  set  up  a problem: 


1.  The  mission  must  be  defined  in  terms  of  the  target,  threat,  and  weapons; 

2.  The  flight  profile  is  defined  using  waypoints  to  describe  flight  segments; 

3.  A suite  of  hardware  (black  boxes)  describing  the  aircraft  is  itemized;  reliability  data 
are  provided  for  each  black  box; 

4.  The  required  mission  functions  are  selected  (typical  functions  include  navigation, 
navigation  update,  target  acquisition,  weapon  delivery,  survivability,  communica- 
tions, refueling,  etc.); 

5.  For  each  function,  the  primary  and  backup  modes  of  operation  must  be  defined;  a 
mode  is  defined  by  specifying  the  performance  capability  of  the  mode  (if  applicable) 
and  assigning  the  hardware  black  boxes  required  to  operate  in  that  mode. 

Figure  2.2.1.1-1  shows  a typical  program  output.  Another  page  is  printed  showing  the 
hardware  items  and  the  number  of  missions  on  which  each  box  failed  or  was  disabled  by 
enemy  fire.  Another  page  shows  each  function,  its  associated  modes,  and  the  number  of 
times  each  mode  was  utilized.  The  output  also  includes  additional  statistical  data  on  the 
occurrence  of  ground  and  airborne  events  as  well  as  mission  cost  data. 

2.2. 1.2  Weapon  Delivery  Error  Analysis  Program 

The  weapon  delivery  analysis  routine  is  a program  for  determining  the  distribution  of 
impact  errors  for  a weapon  system  utilizing  unguided,  unpowered  bombs.  The  routine  is 
capable  of  accommodating  almost  any  weapon  delivery  mechanization  under  the  following 
general  assumptions: 


AEPOUT  COMMAND 

EVENTS, ALL 


GROUND  EVENTS 


GENERAL  MAINTENANCE 

SORTIE  CANCELLED 

NOT  OPERATIONALLY  READY 

EQUIPMENT  ITEM  REPLACED 

REPLACEMENT  UNAVAILABLE 

19 

3 

5 

89 

15 

DETECTED  FAILURE 

129 

FALSE  FAILURE 

9 

UNDETECTED  FAILURE 

10 

AIRCRAFT  ABORT 

A/C  1 

0 

A/C  2 

1 

AIRCRAFT  LOST 

A/C  1 

13 

A/C  2 

25 

A/C  LOST  TO  ENEMY  FIRE 

A/C  1 

5 

A/C  2 

4 

MISSION  ABORT 

5 

LOW  FUEL  ABORT 

0 

DISPLAY  TARGET  DETECTION 

A/C  1 

54 

A/C  2 

62 

VISUAL  TARGET  DETECTION 

A/C  1 

73 

A/C  2 

59 

TARGET  ATTACKED 

TARGET  1 

127 

TARGET  2 

121 

PRIMARY  DESTRUCTION 

TARGET  1 

10 

TARGET  2 

10 

SECONDARY  DESTRUCTION 

TARGET  1 

49 

TARGET  2 

39 

GO-AROUND  FOR  ATTACK 

TARGET  1 

1 

TARGET  2 

5 

Fifiin  2.2.1.1-1.  Simplt  output  for  tko  AEP  oir-to^ouod  mWoo  ooolY«t  proffim. 
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1.  Flat,  nonrotating  earth, 

2.  Linear  transformation  of  component  error  sources  to  impact  errors,  and 

3.  Normal  distribution  for  all  error  sources. 

The  routine  can  be  operated  in  three  modes: 

1.  The  user  can  supply  a weapon  release  algorithm  in  the  form  of  a FORTRAN 
subroutine; 

2.  The  user  can  supply  equations  which  transform  the  sensor  measurements  into 
rectangular  coordinate  estimates  of  position,  velocity,  and  wind  relative  to  the 
target;  thirteen  system  implementations  using  this  technique  are  presently  stored  in 
the  program;  and 

3.  The  third  mode  requires  a user-supplied  FORTRAN  subroutine  duplicating  the 
weapon  release  algorithm  as  in  Model  1;  this  mode  applies  to  systems  which  employ 
filtering  and  for  which  the  user  chooses  to  specify  the  sensor  errors  in  terms  of 
magnitude  and  frequency  characteristics. 


To  set  up  a problem,  the  user  (1)  selects  or  defines  an  aircraft;  (2)  describes  the 
trajectory  in  terms  of  dive  angle,  velocity,  release  altitude,  pull-up  acceleration,  etc.;  (3) 
selects  1 of  the  26  stored  weapons;  and  (4)  selects  contributing  error  sources  (from 
approximately  50  stored  sources).  Figure  2. 2. 1.2-1  shows  a typical  output. 

2.2.1.3  Target  Acquisition  Analysis  Program 

The  AEP  target  acquisition  model  is  a modified  version  of  MARS.\M  11.  The  Multiple 
Airborne  Reconnaissance  Sensor  Asst'ssment  Model  (MARSAM)  is  a tiu’get  acquisition 
{)rogram  developwl  in  1968  for  the  .Aeronautical  Systems  Division,  Wright-Patterson  .\FB, 
Ohio,  by  Honeywell,  Incorporated.  It  was  originally  developed  for  use  in  the  (H'rformance 
assessment  of  rtvonnaissance  sensor  systems  of  varied  types  operating  on  presi  rilH'd  flight 
(irofiles  against  ground  targets  in  specified  background  and  weather  environments. 
MARSAM  11  addresses  those  aspects  of  sensor  performance  related  to  the  capability  of  such 
systems  to  provide  target  identification  detail.  Specifically,  the  types  of  aerial  sensor 
systems  considered  in  the  MARSAM  11  model  are:  frame  and  panoramic  cameras,  television, 
the  visual  observer,  vertical  and  forwitfil-looking  infrared,  side-looking  and  forward-looking 
radar.  An  active  TV’  mixlel  has  lieen  addinl.  The  FLIR  model  has  been  addwl  to  include  the 
mixlulation  transfer  function  (MTF)  data  as  a system  performance  measure.  In  adililion, 
there  is  a storrxl  library  of  characteristic  data  for  numerous  target-elements,  Uu  kground. 
weather,  and  terrain  conditions. 


WfMpon  Dtlnwy  SystMn  Numbar  3 
Constant  Flight  Path  Anglt  Trajactory  With  an  0.317  Thrust  Satting 


Time 

TAS  FPA  Altitude 

Range 

Alpha 

Roll-in 

-1.000 

300.0  -.1 

D 1000.0 

4451.6 

3.7 

Ouiignatt 

-0.000 

300.0  -.1 

D 1000.0 

3945.0 

3.7 

RsImw 

-0.000 

300.0  -.1 

3 1000.0 

3945.0 

3.7 

Minimum  Altitude 

0.020 

300.0  -.0  1000.0 

3934.6 

18.2 

Error  Source  (units) 

1 Along  Track 1- 

1 

Error  Source 

at — 

wm 

Error  Source 

Mks 

Magnitude 

Distance 

Magnitude 

Distance 

16 

Video  Trscker  tot  Angle  (Milt) 

3.0 

3.0 

3.0 

12.2 

17 

Video  Tracker  Angle  Rete  (Mils/t) 

0.5 

34.2 

0.4 

12.9 

18 

Laser  Range  (Ft) 

25.0 

0.4 

0.0 

0.0 

19 

Laser  Range  Rate  (FPS) 

5.0 

-18.7 

0.0 

0.0 

22 

Wind  CorrKtion  (FPS) 

12.5 

-3.1 

12.5 

2.1 

25 

Later  Alignment  (Mils) 

2.0 

-0.6 

0.0 

0.0 

34 

Sideslip  (Mils) 

0.0 

0.0 

1.4 

5.5 

35 

Steering  (Milt) 

0.0 

0.0 

5.0 

19.7 

43 

Bomb  Fall  Algorithm  (Mils) 

1.0 

8.9 

0.0 

0.0 

Praraleeta  Root  Sum  Square 

40.2 

27.1 

49 

Release  Delay  (MSEC) 

20.0 

10.1 

0.0 

0.0 

50 

Ejection  Velocity  (FPS) 

2.0 

29.2 

0.0 

0.0 

51 

Ballistic  Dispersion  (Milt) 

3.0 

26.7 

3.0 

12.2 

Root  Sum  Square 

57.3 

29.7 

l^ohable  Errors  REP  = 38.64 

DEP  ° 20.06 

CEP  = 50.60 

Figurt  2.2.1.2-1.  Slmplt  mapon  dativary  output. 


MARSAM  II  models  the  sensor  system  and  the  operational  environment  in  detail.  It 
contains  models  for  displays,  lenses,  filters,  and  film.  It  considers  the  impact  of  image 
motion  compensation,  platform  stabilization  errors,  backscattering,  and  atmospheric  effects 
on  sensor  performance.  The  human  observer  is  modeled  in  terms  of  ability  to  perceive  the 
target  as  a function  of  size  and  contrast,  display  signal-to-noise  ratio,  presence  of  confusing 
objects,  and  time  in  the  field  of  view.  A search  performance  model  in  human  factors  display 
has  been  added  as  an  option.  Available  outputs  from  MARSAM  include  detailed  sensor 
system  performance  parameters  and  associated  probability  measures  of  detection, 
recognition,  and  identification. 

2.2.1.4  Air-to-Air  Mission  Analysis  Program 

The  Air-to-Air  AEP  mission  analysis  program  is  a Monte  Carlo  simulation  of  two 
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I opposing  aircraft  flights  (up  to  four  aircraft  in  a flight)  through  an  entire  mission.  As  the 

[ flight  progresses,  it  is  influenced  by  hardware  failures,  refueling,  communications  to 

I airborne  or  ground  controllers,  enemy  aircraft  detection  capability,  identification 

■ requirements  and  weapon  capabilities.  Modeling  of  these  functions  varies  considerably  in 

I levels  of  detail  based  upon  impact  on  mission  success  and  initial  model  development 

j priorities.  Detailed  visual,  radar,  and  infrared  detection  models  are  available  for  the  target 

; detection  function. 

When  one  side  detects  the  other,  that  flight  pursues  a course  directly  at  the  other  flight 
, and  fires  when  the  weapon  constraints  are  satisfied.  The  encounter  is  considered  only  until 

1 both  sides  have  detected  the  other.  At  that  time,  the  relative  positions  and  headings  are 

f stored  for  output  so  that  users  can  determine  which  side  has  the  relative  advantages.  Kills 

I occur  only  if  weapons  are  fired  before  detection  by  both  sides  has  occurred.  At  the 

I termination  of  the  engagement,  both  sides  return  to  the  nominal  flight  profile  for  the  return 

I flight. 

The  mission  is  described  by  the  vehicle  hardware  makeup,  flight  profile  and  mission 
functions.  However,  these  must  be  described  for  both  friendly  and  hostile  aircraft.  All 
friendly  aircraft  (and  similarly  all  hostUe  aircraft)  must  be  identically  equipped,  although 
i friendly  need  not  be  the  same  as  hostile. 

i 

I 2.2. 1.5  One-on-One  Dogfight  Analysis  Program 

i 

j A separate,  deterministic  air-to-air  program  permits  analysis  of  the  dogfight  encounter, 

j It  simulates  an  engagement  between  two  fighter  aircraft.  The  logic  for  control  of  aircraft 

maneuvers  is  based  on  lag  pursuit  and  energy  management.  Lag  pursuit  implies  that  each 
aircraft  attempts  to  get  on  the  tail  of  the  other.  Energy  management  control  implies  that  the 
aircraft  seeks  a velocity  and  altitude  for  best  turning  performance.  A comprehensive  on-line 
plot  capability  supports  use  of  the  dogfight  analysis  program.  Users  can  plot  large  numbers 
of  position,  velocity,  and  acceleration  components  in  an  earth  or  aircraft  reference  frame  in 
two  or  three  dimensions.  In  addition,  the  user  can  define  firing  criteria  and  the  program  will 
automatically  examine  the  results  of  a run  to  determine  intervals  when  the  criteria  are 
satisfied. 

2.2.2  Interactive  Graphics  Capability 

An  interactive  graphics  processor  is  available  for  use  with  AEP.  The  purpose  of  this 
processor  is  to  ease  user  difficulty  in  communicating  with  the  computer  and  with  AEP. 
Specifically,  the  processor  has  the  following  characteristics: 
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1.  The  user  develops  input  on-line; 

2.  Input  data  is  stored  on  permanent  files  for  later  reference  or  use  in  other  runs; 

3.  Input  data  are  checked  against  upper  and  lower  limits  to  detect  improper  input; 

4.  The  program  is  executed  in  steps  to  allow  the  user  to  check  reasonableness  of  partial 
executions; 

5.  Output  data  can  be  graphically  displayed  and  hard  copies,  suitable  for  presentations 
or  reports,  can  be  made;  and 

6.  A special  “help”  feature  is  available  to  provide  the  user  with  instructive  comments 
whenever  the  user  is  in  doubt  about  how  to  proceed. 

The  AEP  programs  are  batch  programs,  even  though  they  are  automatically  executed 
from  a remote  interactive  terminal.  The  input  and  output  processors  are  used  to 
communicate  with  the  user  for  problem  setup  and  review  of  the  output.  New  data  is  stored 
in  convenient  subsets  for  later  use.  A very  important  “help”  file  and  a complete  on-line 
user’s  manual  are  available  to  aid  the  user  in  communicating  with  the  processor  and 
associated  programs. 
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Figure  2.2.2-1  shows  an  overall  block  diagram  of  the  interactive  graphics  programs.  The 
user  specifies  the  required  data  by  either  supplying  new  data  or  retrieving  data  previously 
stored.  Once  the  user  is  assured  that  the  data  are  satisfactory,  an  execution  deck  can  be 
requested  and  the  program  can  be  executed.  The  main  programs  produce  an  output  on  a 
permanent  file.  The  interactive  software  then  interrogates  the  output  permanent  file  at  the 
user’s  command  to  produce  the  desired  displays.  The  sample  air-to-ground  mission  analysis 
problem  of  Figure  2, 2.2-2  on  the  following  pages  demonstrates  the  manner  in  which  the 
interactive  software  can  be  used.  Each  section  of  Figure  2.2. 2-2  is  a hard  copy  of  the  actual 
display,  except  for  the  figure  title. 

After  the  user  has  logged  in  and  attached  and  loaded  the  program,  the  logo  of  Section 
(a)  appears.  Since  the  logo  uses  a full  page,  the  user  is  informed  (with  an  audible  “beep” 
from  the  terminal)  that,  at  the  next  step,  the  page  will  be  erased.  Thus,  if  a hard  copy  is 
desired,  it  should  be  made  at  that  time.  On  the  next  page  the  user  is  asked  for  an  AEP 
command.  Note  that  whenever  a double  dash  (-)  appears,  the  program  is  expecting  a user 
input.  Since  the  user  did  not  remember  the  possible  AEP  commands,  a question  mark  (?) 
was  entered.  The  program  then  supplied  all  of  the  possible  commands  and  again  asked  for  an 
AEP  command.  The  user  was  interested  in  the  command  FP  but  wanted  more  information 
about  it,  so  the  command  FP?  was  entered.  The  program  responded  that  FP  was  the  flight 
profile  generation  command  and  again  asked  for  an  AEP  command.  This  time,  the  user 
entered  the  command  FP.  The  requested  entry  was  not  clear,  so  more  information  was 
requested.  Based  on  the  explanation,  the  user  entered  SHOW  and  was  provided  with  a list  of 
stored  flight  profiles.  After  the  user  selected  the  third  flight  profile,  the  program  asked  for 
the  next  FP  command.  A question  mark  provided  a list  of  available  commands  (continued  as 
Section  (c).  The  user  requested  an  explanation  of  the  LIST  and  PLAN  commands  and  then 
commanded  LIST. 

In  Section  (d),  the  flight  profile  waypoints  were  tabulated  and  at  the  completion  of  the 
tabulations  the  next  command  was  requested.  The  user  requested  a “PLAN.”  Since  that 
plan  required  a full  page,  the  user  was  notified  with  a “beep.” 

Figure  2. 2. 2-2  (e)  shows  the  resultant  plan  view  of  the  flight  profile  with  a grid  in 
nautical  mile  units.  Note  that  the  concentration  of  way  points  on  the  right  (near  way  point 
-18)  does  not  allow  a good  view  of  the  profile.  The  user  may  request  an  expanded  plan  view 
of  the  waypoints  in  this  area. 

In  Section  (f)  the  user  requested  an  explanation  of  the  command  CH.XNGE  and  then 
changed  way  (mint  12.  Note  that  the  user  changed  only  the  x and  y coordinates  of  that  way 
point. 
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WELCOME-  YOU  ARE  NOW  CONNECTED  WITH  THE  INTERACT  I UE 
UERSION  OF  THE  AU I ON ICS  EUALUATION  PROGRAM 


OEUELOPEO  BY 

SRTTELLE,  COLUMBUS  LABORATORTES 


(a)  LOGO 


Fifun  2.2.2-2.  Sunpl*  txKution  of  tht  AEP  intoractivo  protnm. 


AEP  COMMAND 


? 

EXECUTIVE  (AEP)  COMMANDS 

EOUIP  SUBF  WD  WDDECK  WDOUT  FP 
MARSAM  AEPDECK  AEPOUT  END  (QUIT) 

AEP  COMMAND 

FP? 

FLIGHT  PROFILE  GENERATION 
AEP  COMMAND 

FP 

FLIGHT  PROFILE  DATA  INPUT 
ENTER  PROFILE  ID 

? 

ENTER  NUMBER  ID  OF  STORED  PROFILE,  ENTER  0 TO  CREATE  NEW  PROFILE 
ENTER  SHOW  FOR  LIST  OF  STORED  PROFILES 
ENTER  PROFILE  ID 
SHOW 

1 SAMPLE  PROFILE  FOR  FINAL  REPORT  JAN  73 

2 RPV  SAMPLE  PROFILE 

3 SAMPLE  PROFILE 
ENTER  PROFILE  ID 

3 

FP  COMMAND  - 

? 

FLIGHT  PROFILE  (FP)  COMMANDS 

ENTER  VALID  COMMAND  WITH  REQUIRED  PARAMETER  LIST 
I D O LIST  FLY  PLAN  ALT  VEL  SAVE  QUIT 
FP  COMMAND  - 

LIST? 


(b)  Interactive  Dialogue 


Figurt  Z2.2-2  (con.),  Simpio  cxocution  of  the  AEP  intoroctivt  program. 
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DISPLAY  LIST  OF  CURRENT  VALUES  POINTS  ARE  RESEQUENCED  TO 
REFLECT  PREVIOUS  COMMANDS 
FP  COMMAND  - 

PLAN? 

DRAWS  A PLAN  VIEW  OF  THE  PROFILE.  ENTER  THE  COMMAND  AS 
FOLLOWS 
PLAN.  ID1.  ID2 

POINTS  ID1  THRU  ID2  ARE  PLOTTED 

IF  ID2  IS  OMITTED.  ALL  POINTS  FROM  ID1  ON  ARE  PLOTTED 
IF  BOTH  PARAMETERS  OMITTED  ALL  POINTS  ARE  PLOTTED 
FP  COMMAND  - 

LIST 


(c)  Interactive  Dialogue  (continued) 


FtfMra  1.2.7  2 (can.).  Samplt  aNMuKon  of  Itit  AEP  inttrictiw  progrim. 
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ID 

X 

X 

H 

V 

ON 

OFF 

1 

0.00 

0.00 

0. 

150. 

701  702 

1201 

2 

35.00 

-20.00 

20000. 

450. 

3 

127.50 

0.00 

20000. 

450. 

4 

150.00 

0.00 

5000. 

162. 

5 

160.00 

0.00 

5000. 

162. 

6 

160.00 

10.00 

5000. 

162. 

7 

150.00 

10.00 

5000. 

162. 

8 

150.00 

15.00 

5000. 

250. 

9 

160.00 

20.00 

5000. 

162. 

10 

180.00 

30.00 

5000. 

300. 

303  901 

11 

185.00 

35.00 

2500. 

250. 

1102 

3 

12 

188.00 

38.00 

2500. 

250. 

13 

185.00 

30.00 

2500. 

250. 

14 

180.00 

30.00 

2500. 

250. 

15 

180.00 

35.00 

2500. 

250. 

702 

7 

16 

189.00 

39.00 

2500. 

250. 

11 

17 

190.00 

40.00 

2500. 

300. 

18 

190.00 

45.00 

5000. 

450. 

19 

155.00 

29.00 

20000. 

450. 

20 

30.00 

60.00 

20000. 

450. 

21 

20.00 

15.00 

20000. 

450. 

22 

0.00 

0.00 

0. 

150. 

1 

FP  COMMAND  ~ 

PLAN 

9 


12 


(d)  Way  Point  Description 


Figure  2.2.1-1  (con.).  Sample  execution  of  the  AEP  interactive  program. 


160 


FP  COMMAND  - 


C? 

CHANGE  VALUES  AT  WAYPOINT  ENTER  COMMAND  AS 
C,ID,X.Y,H,V,  ON.OFF 

ID=POINT  TO  BE  MODIFIED 

X.Y=COORDINATES(NM),  H=ALTITUDE(FT),  V=SPEED(KTS), 

ON=FUNCTIONS  TURNED  ON,  OFF=FUNCTIONS  TURNED  OFF 
FIVE  ON  OFF  NUMBERS  MAY  BE  ENTERED 

THE  14  INPUT  PARAMETERS  X THRU  OFF(5)  MAY  BE  ENTERED  WITHOUT 
THE  LETTER  CODE.  ONLY  PARAMETERS  SPECIFIED  ARE  CHANGED. 
IF  PARAMETERS  ARE  SKIPPED,  LETTER  CODE  MUST  BE  USED 
EX-  CHANGE,4,100.,10.,V=250.  SETS  X=100.,Y=10.,V=250.  FOR  POINT  4 
FP  COMMAND  - 
— C,12,195.38 

FP  COMMAND  - 

PLAN,  10,18 


(f)  Cominand  Explanation  Request 


Figur*  ZZ2-2  (con.).  Sampit  oxocution  of  the  AEP  intoractivo  program. 
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"■"rrsaaiisjf --  ■ ■ --cry 


FP  COMMAND  - 

SAVE 

ENTER  TITLE,  UP  TO  60  CHARACTERS 

SAMPLE  FLIGHT  PROFILE  CREATED  6/25/73 
SAMPLE  FLIGHT  PROFILE  CREATED  6/25/73 
IS  TITLE  O.K.,  Y OR  N 
Y 

DO  YOU  WANT  TO  DELETE  ANY  TRAJECTORIES,  Y OR  N 
N 

AEP  COMMAND 


QUIT 


HEP  FINISHED 
EXIT 

COMMAND- 


(g)  Program  Exit 


Fifurt  2.2.Z-1  (con.).  Somplo  oxocutian  of  tho  AEP  iotoractivo  proirnn. 
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In  Section  (g)  the  user  exited  the  program.  Note  that  the  user  must  respond  to  several 
questions  before  an  exit  is  allowed.  This  provides  the  user  with  an  opportunity  to  save  data 
and  to  enter  comments  for  later  reference. 

This  example  serves  to  demonstrate  the  main  features  of  the  interactive  graphics 
processor.  It  should  further  be  noted  that  the  interactive  portions  of  the  program  provide 
the  user  with  a wide  variety  of  displays  both  on  program  set-up  and  during  program 
execution.  The  various  references  should  be  consulted  for  an  indepth  discussion  of  these 
capabilities. 

2.2.3  Program  Set-up 

In  setting  up  the  AEP,  missions  (i.e.,  A/G,  A/ A,  etc.)  are  defined  by  specifying  a flight 
profile  as  a sequence  of  way  points  with  associated  tactical  functions  and  by  specifying  a 
vehicle  hardware  makeup  as  a set  of  subsystems  to  support  these  tactical  functions. 

2.2.3.1  Flight  Profile 

Each  waypoint  along  the  flight  profile  will  generally  reflect  a change  in  direction  or 
airspeed  or  a change  in  the  functions  utilized  (the  definition  of  a function  will  become  clear 
in  subsequent  paragraphs).  Each  waypoint  is  described  by  providing: 

1.  the  distance  east  of  the  origin  (base), 

2.  the  distance  north  of  the  origin, 

3.  aircraft  altitude  above  MSL,  and 

4.  aircraft  velocity. 

From  this  information,  heading  and  flight  path  angle  are  determined  by  a straight  line 
trajectory  between  waypoints.  Changes  in  vertical  flight  path  angle  occur  instantaneously 
while  changes  in  heading  are  achieved  with  a constant  bank  angle  coordinated  turn.  Changes 
in  velocity  occur  immediately  upon  leaving  a waypoint.  Acceleration  incorporates  full 
throttle  while  deceleration  incorporates  idle  thrust. 

2.2.3.2  Functions,  Subfunctions,  Modes  and  States 

As  a part  of  the  flight  profile,  mission  functions  are  specified  over  appropriate  time 
intervals.  A function  is  defined  as  an  operation  or  action  performed  during  the  mission. 
Functions  may  further  be  divided  into  associated  sub-functions  which  are  alternative 
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options  for  performing  a particular  function.  A table  of  functions  and  subfunctions  is 
indicated  in  table  2.2. 3-1  for  the  air-to-ground  and  air-to-air  versions  of  AEP.  A more 
detailed  description  of  existing  functions  and  subfunctions  is  included  in  subsequent 
sections. 

2.2.3.2.1  Air-to-ground  functions  and  subfunctions 

2.2.3.2.1.1  Scheduled  Maintenance.  The  scheduled  maintenance  function  provides  an 


TABLE  2.2.3-1.  A/G  AND  A/A  FUNCTIONS  AND  SUBFUNCTIONS 


Air-To-Ground 

Air-To-Air 

Functions 

Sub  functions 

Functions 

Subfunctions 

Scheduled  maintenance 

Preflight 

Navigation 

Ground  controlled  intercept 

Thru  flight 

Airborne  controlled  intercept 

Postflight 

Communications 

Interflight  communications 

Ordinance 

General  purpose  munitions 

External  communications 

Rockets 

Fuel 

Fuel  utilization 

Fueling 

Fuel  loading 

Refueling 

Fuel  usage 

Target  detection 

Visual 

Refueling 

Radar 

Flight 

Launch 

Infrared 

Inflight  aircraft  abort 

Target  identification 

Electronic  IFF 

Mission  abort 

Television 

Loss  of  aircraft 

Visual 

Landing 

Engagement 

Semi-Ktive  radar  missile 

Mission 

Schedule 

IR  missile 

Cost  accumulation 

Formation 

Formation 

Formation 

Nominal  flight 

Maneuver 

Weaving  escort 

Navigation 

Radio-aided 

Weapon  detection 

Visual 

Self-contained 

Radar 

Navigation  update 

Automatic  navigation  update 

Infrared 

Radar  navigation  update 

Mandatory  operations 

Aircraft  abort 

Visual  navigation  update 

Aircraft  lots 

Communications 

Intarf  light 

External 

Survivability 

Survivability  subfunctions  (5) 

Target  Kquisition 

Display  acquisition 

Visual  acquisition 

Weapon  delivery 

Manual  weapon  delivery 

Automatic  weapon  delivery 

Target 

Target  subfunctions  (SI 
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assessment  of  the  time  involved  to  keep  aircraft  ready  for  f1i::hL.  Three  subfunctions  are 
provided  to  account  for  preflight  (beginning  of  day),  thru-flight  (between  sorties),  and 
postflight  (end  of  day)  maintenance.  Data  required  to  describe  the  ground  maintenance 
are:  mean  duration,  standard  deviation,  and  equipment  checklist.  The  random  service  time 
is  drawn  from  a log-normal  distribution  defined  by  the  input  parameters.  It  is  assumed  that 
the  repair  of  items  in  the  checklist  occurs  in  parallel  with  the  maintenance  time,  and  that 
repair  of  other  items  is  in  series. 

The  preflight  subfunction  sequences  each  aircraft  to  ordnance  loading  at  the  completion 
of  the  maintenance  interval.  If  one  or  more  aircraft  become  NORS,  the  remainder  of  the 
day  is  cancelled. 

The  throughflight  subfunction  sequences  each  aircraft  to  ordnance  dearming  at  the 
completion  of  maintenance.  In  reality,  dearming  would  occur  prior  to  ground  service. 
However,  for  convenience  in  programming  and  since  the  total  time  interval  is  the  same, 
throughflight  and  dearming  times  are  reversed.  As  with  preflight,  a NORS  state  cancels  the 
day. 

The  postflight  subfunction  sequences  each  aircraft  to  ordnance  dearming  at  the 
completion  of  maintenance.  Since  postflight  occurs  at  the  end  of  the  day’s  sorties,  a NORS 
state  has  no  impact.  All  redundant  items  are  repaired  during  postflight  maintenance. 

2.2.3.2.1.2  Ordnance.  The  ordnance  function  calculates  the  time  required  to  load  and 
arm  the  ordnance  prior  to  each  sortie,  and  also  calculates  the  time  required  to  unload  and 
dearm  the  ordnance  at  the  end  of  each  sortie.  There  are  two  ordnance  subfunctions— general 
purpose  munitions  and  rockets.  The  logic  within  the  subfunctions  is  identical.  The 
difference  lies  in  the  distributions  which  describe  the  loading  and  unloading  times  of  the 
different  munitions.  The  input  items  for  each  subfunction  are:  the  number  of  weapons 
carried,  the  mean  and  standard  deviation  of  the  loading,  plus  arming  time  per  weapon,  and 
the  mean  and  standard  deviation  of  the  unloading  plus  dearming  time  per  weapon. 

2.2.3.2.1.3  Fuel.  The  fuel  function  provides  a means  of  managing  the  aircraft  fuel 
requirements.  Three  subfunctions  are  available  for  fuel  loading,  monitoring  of  fuel  used,  and 
air  refueling.  The  fuel  flow  rate  during  flight  is  one  of  the  aircraft  states  provided  by  the 
aircraft  flight  simulation.  An  aircraft  abort  occurs  if  fuel  monitoring  or  refueling  status  are 
unavailable.  A mission  abort  occurs  if  no  modes  are  available  for  air-refueling. 

The  fuel  usage  subfunction  aborts  an  aircraft  if  the  remaining  fuel  is  less  than  that 
required  to  complete  the  flight  plus  the  required  reserve. 
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The  air  refueling  subfunction  determines  the  time  of  hookup  from  a uniform  probability 
distribution  specified  on  input  by  the  minimum  and  maximum  hookup  times.  Several 
aircraft  can  be  refueled  simultaneously,  the  exact  number  being  specified  as  input.  The  time 
required  to  refuel  is  calculated  as  a function  of  the  amount  of  fuel  to  be  loaded  and  the 
refueling  rate,  which  is  also  specified  as  input. 


2.2.3.2.1.4  Flight  The  flight  function  provides  a means  of  specifying  the  equipment 
requirements  for  various  portions  of  the  mission.  Five  subfunctions  are  available:  launch, 
inflight  abort,  mission  abort,  aircraft  loss,  and  landing. 


[ 


The  launch  subfunction  iraws  a random  sortie  launch  time  from  a >og-normal 
distribution  defined  by  the  input  data.  This  time  represents  the  interval  between  engine  start 
and  takeoff.  At  takeoff,  subfunctions  2-4  are  turned  on,  and  launch  is  turned  off.  The 
launch  subfunction  uses  only  the  time  data  given  with  the  first  mode.  A ground  abort  of  the 
mission  occurs  if  either  an  aircraft  has  no  available  equipment  state,  or  no  mode 
requirement  is  satisfied. 

There  are  no  program  calculations  associated  with  the  aircraft  abort  subfunction.  The 
aircraft  equipment  states  associated  with  this  subfunction  allow  determination  of  an  abort 
situation.  In  addition,  an  aircraft  abort  will  occur  if  the  aircraft  does  not  satisfy  some  mode 
requirement.  This  is  a unique  use  of  the  mode  definition  for  this  subfunction. 

The  mode/state  requirements  for  the  mission  abort  subfunction  are  used  to  define  when 
a sortie  must  be  aborted.  If  no  mode  is  available,  the  mission  is  aborted. 

The  aircraft  loss  subfunction  is  used  to  define  the  set  of  equipment  required  to  keep  an 
aircraft  airborne.  If  no  aircraft  equipment  state  is  available,  the  aircraft  is  lost. 

The  landing  subfunction  is  used  to  define  the  set  of  equipment  required  to  make  a 
successful  landing.  If  no  landing  equipment  state  is  available,  the  aircraft  is  counted  as  lost. 

2.2.3.2.1.5  Mission.  The  mission  function  provides  a means  of  specifying  the 
operations  schedule  and  the  cost  of  various  portions  of  the  mission.  There  are  no  nominal 
calculations,  aircraft  aborts,  or  mission  aborts  associated  with  this  function. 

The  schedule  subfunction  is  the  overall  mission  scheduler  for  the  nominal  portion  of  the 
simulation.  The  schedule,  utilizing  the  input  data,  manages  the  starting  times  for  the 
individual  sorties  and  the  individual  data.  All  maintenance  actions  and  all  flights  are 
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controlled  by  this  subfunction.  If  a delay  occurs  in  the  ground  maintenance  functions,  the 
scheduler  may  cancel  a sortie  if  the  input  maximum  delay  times  are  exceeded.  This 
subfunction  is  called  initially  to  begin  the  simulation,  at  the  end  of  throughflight  and 
preflight  maintenance,  and  at  the  end  of  each  sortie. 

2.2.3.2.1.6  Formation.  The  purpose  of  the  formation  function  is  to  specify  the 
position  of  flight  members  relative  to  the  lead  aircraft.  The  user  specifies  the  distance  right, 
behind,  and  above  the  leader  for  up  to  three  supporting  elements. 

2.2.3.2.1.7  Navigation.  The  navigation  function  includes  two  subfunctions— radio-aided 
navigation  and  self-contained  navigation.  The  two  subfunctions  provide  the  capability  of 
computing  and  considering  navigation  errors.  Two  types  of  navigation  errors  are 
considered— a fixed  position  navigation  error  and  a per  unit  time  error.  A mission  abort 
occurs  if  the  self-contained  navigation  subfunction  fails.  If  the  radio-aided  navigation  fails,  a 
switch  to  self-contained  navigation  is  attempted.  If  the  switch  is  successful,  the  mission  is 
continued;  otherwise,  a mission  abort  occurs. 

2. 2. 3. 2. 1.8  Navigation  Update.  The  navigation  update  function  includes  three 
subfunctions;  automatic  update,  radar  update,  and  visual  update.  The  navigation  update 
subfunctions  calculate  the  sensor  field  of  view  and  determine  if  the  checkpoint  is  within  the 
field  of  view,  and  if  the  checkpoint  has  been  detected.  Once  the  checkpoint  has  been 
detected,  the  accuracy  of  the  navigation  update  is  computed. 

2. 2.3.2. 1.9  Communications.  Two  communications  subfunctions  are  provided  to  assess 
the  reliability  of  the  communications  equipment:  interflight  and  external  communications. 
Loss  of  all  aircraft  equipment  states  for  interflight  communications  causes  an  aircraft  abort. 
Loss  of  all  modes  for  either  subfunction  causes  a mission  aboit. 

2.2.3.2.1.10  Survivability.  The  survivability  subfunctions  have  two  primary  purposes. 
The  first  is  to  generate  a random  time  of  hit  for  each  aircraft  from  an  exponential 
distribution  specified  on  input.  The  second  purpose  is  to  process  the  aircraft  hits  to  assess 
aircraft  damage.  The  input  data  items  at  the  constant  probability  of  hit,  the  per  unit  time 
probability  of  hit,  and  the  probability  of  aircraft  kill.  Five  subfunctions  are  provided  so  that 
the  user  may  have  direct  control  over  when  each  is  used.  For  example,  a typical  mission 
profile  may  progress  through  defensive  zones  with  different  probabilities  of  survival.  The 
user  can  key  the  use  of  each  subfunction  (with  different  data)  to  waypoints  defining  the 
flight  profile. 
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2.2.3.2.1.11  Target  Acquisition.  Display  and  visual  target  acquisition  subfunctions  are 
provided.  All  targets  specified  by  the  user  are  checked  for  detection  during  each  search 
segment,  with  attack  passes  occurring  based  on  the  sequence  of  detection.  Thus,  for 
relatively  close  targets,  the  order  of  attack  can  be  different  than  the  order  of  target 
locations.  After  an  attack  against  one  target,  the  acquisition  process  is  resumed  for  the 
remaining  targets,  allowing  a user  to  simulate  a target  of  opportunity  type  mission.  There 
are  no  aircraft  aborts  due  to  loss  of  acquisition  equipment  items.  A mission  abort  occurs 
only  if  all  possible  modes  of  both  subfunctions  fail. 

2.2.3.2.1.12  Weapon  Delivery.  Manual  and  automatic  weapon  delivery  subfunctions  are 
available.  A significant  feature  of  the  updated  weapon  delivery  function  is  that  ordnance 
and  target  types  are  keyed  to  the  delivery  modes.  This  provides  the  flexibility  of  considering 
various  ordnance  mixes  for  a multiple  target  sortie.  A unique  feature  of  the  weapon  delivery 
function  is  that  a subfunction/mode  status  is  maintained  for  each  aircraft.  Thus,  it  is 
possible  for  one  aircraft  to  use  the  automatic  release  subfunction  and  another  aircraft  to  use 
the  manual  subfunction.  Mode  changes  due  to  equipment  failure  have  no  immediate  impact 
if  weapon  delivery  has  not  been  activated.  When  a weapon  delivery  run  is  committed  and  a 
mode  regression  occurs,  only  a mode  with  a release  range  matching  the  committed  range  will 
be  used.  Otherwise,  the  aircraft  with  the  failure  cannot  attack  on  that  pass.  An  individual 
aircraft  does  not  abort  if  no  equipment  states  remain.  If  that  aircraft  was  initially  in  the 
automatic  subfunction,  the  manual  subfunction  will  be  used  if  possible.  If  none  of  the 
aircraft  can  perform  the  weapon  delivery  function,  the  mission  is  aborted. 

2.2.3.2.1.13  Target.  The  target  function  manages  the  number  of  attack  passes  and 
target  location  uncertainty  for  up  to  five  targets.  This  information  is  specified  on  input. 
There  are  two  levels  of  target  destruction  accumulated,  primary  and  secondary  destruction, 
which  are  based  on  primary  and  secondary  kill  radii. 

2.2.3.2.2  Air-to-air  functions  and  subfunctions 

2.2.3.2.2.1  Navigation  Function.  The  primary  purpose  of  introducing  a navigation 
function  is  to  have  a mechanism  for  reflecting  the  influence  of  navigation  on  target 
detection.  No  influence  of  onboard  navigation  system  errors  are  considered.  Navigation  is 
important  on  an  intercept  mission  where  a supporting  ground  or  airborne  element  is 
providing  an  alert  or  intercept  vectors.  The  quality  of  the  vectors  is  not  addressed.  The 
effect  of  the  supporting  element  is  to  place  the  airborne  flight  in  an  alerted  or  vectored 
status.  The  implications  of  this  status  are: 
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1.  In  autonomous  search  (no  supporting  element),  three  sweep  detections  are  required 
to  adequately  assess  target  position  and  direction  of  flight, 

2.  In  alerted  search,  two  sweep  detections  are  required;  and 

3.  In  vectored  search,  one  sweep  detection  is  required. 

The  navigation  subfuncticns  draw  random  numbers  to  determine  this  status. 

The  input  data  items  are: 

1.  Probability  that  the  controller  detects  the  enemy  flight,  and 

2.  Probability  that  sufficient  information  is  available  for  vectored  search. 

No  action  is  taken  if  these  subfunctions  are  lost. 

2.2.3.2.2.2  Interflight  Communications  Subfunction.  The  interflight  communications 
subfunction  calculates  a delay  in  transmitting  target  detection  from  one  flight  member  to 
the  rest  of  the  flight.  The  input  data  items  are: 

1.  Communication  frequency  utilization, 

2.  Mean  duration  of  the  utilization, 

3.  Maximum  communication  delay,  and 

4.  Time  to  communicate. 

The  first  input  data  item  is  a number  between  zero  and  one  expressing  the  probability 
that  the  communication  frequency  is  being  utilized  when  a flight  member  attempts  to 
transmit.  The  second  item  is  the  mean  value  of  the  duration  of  interference.  This  item 
defines  an  exponential  probability  distribution  of  delay.  The  delay  is  limited  by  an  input 
maximum  delay.  This  subfunction  is  called  by  the  detection  function.  If  the  user  does  not 
select  this  subfunction,  no  delay  is  calculated.  If  this  subfunction  is  lost,  the  mission  is 
aborted. 

2.2.3.2.2.3  External  Communications  Subfunction.  The  external  communications 
subfunction  calculates  delay  in  communicating  controller  alerts  or  vectors  to  the  airborne 
flight.  The  input  data  items  are: 

1.  Communication  frequency  utilization, 

2.  Mean  duration  of  utilization, 

3.  Maximum  time  of  utilization. 
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4.  Probability  of  ECM  interference, 

5.  Mean  delay  of  ECM  interference,  and 

6.  Maximum  vector  update  period  required  to  maintain  vectored  status. 

The  delay  is  calculated  in  the  same  way  as  for  interflight  communications,  except  that 
jamming  of  the  link  is  an  added  possibility.  An  exponential  distribution  is  used  for  the 
duration  of  jamming  when  it  occurs.  The  purpose  of  this  subfunction  is  to  determine  delay 
in  communicating  the  alert  or  vector  status.  A vectored  status  must  be  updated  at  the  end  of 
each  update  period.  Thus  the  flight  can  oscillate  between  alerted  and  vectored  status  if  there 
are  communication  delays.  If  this  subfunction  is  not  selected,  no  delays  are  calculated.  If 
this  subfunction  is  lost,  no  action  is  taken. 

2.2.3.2.2.4  Fuel  Utilization  Subfunction.  This  subfunction  aborts  the  aircraft  if  the 
remaining  fuel  is  less  than  that  required  to  complete  the  flight  plus  the  required  reserve.  The 

I subfunction  is  called  periodically  (when  it  is  on),  based  on  the  flow  rate  and  fuel  status.  The 

input  data  item  is  the  reserve  fuel  requirement  measured  in  pounds.  If  this  subfunction  is 
lost,  the  mission  is  aborted. 

2.2.3.2.2.5  Refueling  Subfunction.  Refueling  occurs  when  this  subfunction  is  turned 

! on.  Hookup  time  is  determined  from  a uniform  probability  distribution  specified  by  the 

i minimum  and  maximum  hookup  time.  Several  aircraft  can  be  refueled  simultaneously.  The 

I time  to  refuel  is  a function  of  the  refueling  rate  and  amount  of  fuel  to  be  added.  The  input 

data  items  are: 

1.  Minimum  hookup  time, 

2.  Maximum  hookup  time, 

3.  Refueling  rate  (Ib/min),  and 

4.  Number  of  aircraft  refueled  simultaneously. 

If  this  subfunction  is  lost,  the  mission  is  aborted. 

2.2.3.2.2.6  Visual  Detection  Subfunction.  The  visual  detection  subfunction  has 
computations  in  both  the  nominal  and  Monte  Carlo  portions  of  the  AEP.  The  purpose  of 
the  nominal  evaluation  is  to  compute  the  cumulative  probability  of  detection  as  a function 
of  time  for  each  aircraft.  The  cumulative  probability  is  applicable  as  long  as  the  opposing 
aircraft  fly  the  nominal  trajectory.  If  the  opposing  flight  intentionally  departs  from  the 
nominal,  detection  is  computed  ba.'^ed  on  the  mean  detection  range  (from  a Rayleigh 
distribution). 


The  input  data  items  for  this  function  are; 


1.  Azimuth  field  of  view  search  limits  for  each  aircraft— half  angle  symmetrical  about 
the  nose  (degree), 

2.  Maximum  elevation  search  angle  (degree), 

3.  Time  for  an  individual  scan  for  each  aircraft, 

4.  Ratio  of  time  spent  searching  to  total  time  for  each  aircraft, 

5.  Meteorological  visibility  (nmi), 

6.  Background  luminance  (typically  1,000), 

7.  Target  luminance  (typically  2,200), 

8.  Sky-background  brightness  ratio  (typically  five), 

9.  Contrast  compensation  factor  for  observers  (typically  1 for  good  observer,  .5  for 
untrained  observer), 

10.  Contrast  compensation  factor  due  to  target  shape,  and 

11.  Mean  detection  range  for  off-nominal  closing  aircraft  (nmi). 

If  this  subfunction  is  lost,  the  flight  is  aborted. 

2.2.3.2.2.7  Radar  Detection  Subfunction.  The  radar  subfunction  has  computations  in 
both  the  nominal  and  Monte  Carlo  portions  of  the  AIRAEP.  The  program  models  a high 
PRF  pulse  Doppler  radar.  The  purpose  of  the  nominal  evaluation  is  to  compute  the 
cumulative  and  single  look  probabilities  of  detection  as  a function  of  time.  If  the  opposing 
flight  intentionally  departs  from  the  nominal,  detection  time  is  recomputed  within  the 
Monte  Carlo. 

The  input  data  items  are: 

1.  Azimuth  coverage  for  each  aircraft-total  angle-symmetrical  about  the  nose  (degree), 

2.  Elevation  angle  of  the  composite  beam  center  (degree), 

3.  Width  of  the  composite  lieam  in  elevation— for  multiple  bar  search  use  the  total 
width  (degree), 

4.  Frame  time— time  to  complete  one  sweep  cycle  (degree), 

5.  Dwell  time— time  that  the  beam  would  illuminate  a point  in  space  as  it  sweeps  across 
the  point  (s), 

6.  Probability  of  the  radar  operator  observing  a single  scan,  and 

7.  Terrain  reflectivity  tlypically  .1). 

This  suhfunction  uses  several  other  data  items  entered  under  the  radar  nnd  main  beam 
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clutter  filter  equipment  items.  In  addition,  it  uses  selected  tables  of  aircraft  radar  cross 
section.  If  this  subfunction  is  lost,  the  mission  is  aborted. 

2. 2. 3. 2. 2.8  IR  Detection  Subfunction.  The  infrared  detection  subfunction  has 
computations  in  both  the  nominal  and  Monte  Carlo  portions  of  the  AIRAEP.  The  purpose 
of  the  nominal  evaluation  is  to  compute  the  cumulative  probability  of  detection  as  a 
function  of  time  for  each  aircraft.  The  cumulative  probability  is  applicable  as  long  as  the 
opposing  aircraft  fly  the  nominal  trajectory.  If  the  opposing  flight  intentionally  departs 
from  the  nominal,  detection  is  computed  based  on  the  mean  detection  range  (from  a 
Rayleigh  distribution). 

The  input  data  items  for  this  function  are: 

1.  Upward  elevation  limit  (degree), 

2.  Downward  elevation  limit  (degree), 

3.  Frame  time  (s), 

4.  Collecting  aperture  area  of  the  optics  (cm^ ), 

5.  Focal  length  (cm), 

6.  Instantaneous  detector  FOV  (degree), 

7.  Electrical  filter  factor  (typically  near  1.0), 

8.  Probability  of  an  operator  observing  a detection, 

9.  False  alarm  number  (typically  10.**6), 

10.  Atmospheric  model, 

11.  Haze, 

12.  Visual  range  at  sea  level  (km),  and 

13.  Target  radiant  intensity  (watts/cm^  /ster). 

If  this  subfunction  is  lost,  the  mission  is  aborted. 

2.2.3.2.2.9  Target  Identification  Function.  This  function  is  called  after  detection  has 
been  completed.  If  this  function  is  not  selected  by  the  user,  identification  is  assumed  not  to 
be  required  and  the  program  immediately  sequences  to  the  engagement  function. 
Identification  can  occur  via  an  electronic  IFF,  TV  display,  or  visual  subfunction.  The 
electronic  IFF  subfunction  draws  a random  number  for  each  aircraft  to  determine  whether 
IFF  is  possible.  If  the  draw  is  affirmative,  another  number  is  drawn  from  a Rayleigh 
distribution  to  determine  the  time  required  for  identification.  The  TV  and  visual 
identification  subfunctions  require  the  user  to  specify  a mean  identification  range.  This  is 
used  to  describe  a Rayleigh  distribution  from  which  the  identification  time  can  be 
determined. 


The  input  data  items  for  the  electronic  IFF  are: 

1.  Probability  that  identification  can  be  achieved, 

2.  Mean  delay  (s),  and 

3.  Maximum  delay  (s). 

The  input  data  item  for  the  TV  and  visual  subfunctions  is  the  mean  identification  range 
(nmi).  If  any  of  these  subfunctions  are  lost  the  mission  is  aborted. 

2.2.3.2.2.10  Engagement  Function.  The  engagement  is  halted  whenever  both  sides  have 
detected  each  other.  When  a weapon  reaches  the  target  flight,  it  is  assumed  that  that  flight 
detects  the  attacker.  After  the  engagement  is  halted,  all  of  the  airborne  weapons  are 
processed  to  determine  their  effect.  However,  no  additional  weapons  are  fired.  At  the 
beginning  of  the  attack,  the  attacking  flight  heads  directly  toward  the  target  flight. 

The  input  data  items  for  both  the  radar  and  IR  missile  engagement  are: 

1.  Maximum  firing  range  (nmi), 

2.  Minimum  firing  range  (nmi), 

3.  Maximum  azimuth  launch  envelope  (degree), 

4.  Maximum  upper  launch  envelope  (degree), 

5.  Maximum  lower  launch  angle  (degree), 

6.  Number  of  missiles, 

7.  Number  of  missiles  per  salvo, 

8.  Time  between  salvos  (s), 

9.  Initial  launch  delay  (s), 

10.  Missile  reliability, 

11.  Probability  of  target  kill,  and 

12.  Missile  velocity  (kn). 

If  either  subfunction  is  lost,  the  mission  is  aborted. 

2.2.3.2.2.11  Formation  Subfunction.  The  purpose  of  this  function  is  to  specify  the 
position  of  flight  members  relative  to  the  lead  aircraft.  The  user  specifies  the  distance  right, 
behind,  and  above  the  leader  for  up  to  three  supporting  elements. 

2.2.3.2.2.12  Weaving  Escort  Maneuver  Subfunction.  The  purpose  of  the  maneuver 
function  is  to  define  characteristics  of  specific  maneuvers  that  are  not  incorporated  in  the 
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nominal  flight  profile  definition.  This  subfunction  creates  a weaving  escort  pattern.  This 
pattern  is  used  to  support  a slower  moving  aircraft.  The  user  specifies  the  width  of  the 
pattern  (nmi)  and  the  mean  velocity  of  the  aircraft  being  escorted  (kn).  The  program  then 
internally  generates  new  waypoints  based  on  the  difference  between  the  fighter  aircraft 
velocity  and  mean  velocity.  If  the  flight  is  composed  of  more  than  two  aircraft,  then  two 
aircraft  fly  a mirror  image  of  that  pattern.  The  reason  for  providing  this  function  was  to 
preclude  requiring  users  to  define  the  internally  generated  waypoints  where  repeating 
patterns  were  desired. 


2.2.3.2.2.13  Weapon  Detection  Function.  Weapon  detection  occurs  automatically  if  a 
missile  intercepts  the  target  flight.  The  purpose  of  adding  this  function  is  to  allow  a 
modified  kill  probability  if  the  target  flight  detects  the  approaching  missile  early  enough. 
However,  at  present,  a single  kill  probability  is  used  regardless  of  when  detection  occurs. 
The  input  data  items  are; 

1.  Probability  of  missile  detection,  and 

2.  Mean  detection  range  (nmi). 

If  this  subfunction  is  lost,  the  mission  is  aborted. 

2.2.3.2.2.14  Mandatory  Operations  Function.  This  is  a special  function  used  to  define 
critical  elements  of  the  aircraft.  If  the  first  subfunction  is  lost,  the  aircraft  aborts.  If  the 
second  is  lost,  the  aircraft  is  lost. 

2.2.3.2.3  Modes  and  states 

A mode  is  defined  as  a suite  of  subsystems  which  allows  a particular  function  to  be 
performed.  Several  operating  modes  are  possible  for  each  function  or  subfunction  (primary 
and  backup  operating  modes).  The  concept  of  modes  is  quite  straightforward  for  a 
one-aircraft  simulation.  In  that  case,  there  is  a suite  of  hardware  and  performance  data 
associated  with  each  mode.  Presumably,  a user  sets  up  a problem  such  that  the  first  mode 
represents  the  best  performance  and  subsequent  modes  represent  degraded  performance 
with  less  demanding  hardware  requirements. 

The  introduction  of  multiple  aircraft  complicates  the  problem.  Modes  must  now  apply 
to  the  complete  flight.  Thus,  when  entering  data  for  a mode  belonging  to  the  radar 
detection  subfunction,  the  user  specifies  data  applicable  to  all  aircraft  in  the  flight.  Some  of 
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tho  data  art*  the  same  fur  all  aircraft  in  the  flight.  Hut  other  data,  such  as  field  of  view  and 
frame  time,  must  he  spwified  for  each  aircraft,  all  as  part  of  the  same  operating  mode.  A 
backup  mode  may  be  required  if  one  of  the  aircraft  loses  a hardware  item  or  aborts  the 
mission.  The  user  defines  mode  regression  criteria  using  subfunction  states.  A subfunction 
state  defines  the  equipment  sU»tus  for  each  aircraft  for  that  subfunction.  The  user  defines 
staU's  for  a single  aircraft  for  each  selected  subfunction.  AssociaUnl  with  each  state  is  a suiU* 
of  hardware  selected  from  the  available  equipment  candidates.  Htised  on  the  definition  of 
these  slates,  the  user  uses  Boolean  and/or  logic  to  define  criteria  for  In'ing  in  each  nuale.  For 
example,  mcxle  1 of  a given  subfunction  may  require  that  aircraft  A,  B,  and  C be  in  the 
prmuury  state  and  that  aircraft  D be  no  lower  than  state  11.  If  this  criteria  was  not  satisfaxl 
Ix'cause  of  failure  of  some  equipment,  mode  regression  would  occur. 

2.2.3.3  Aircraft  Equipment 

.Ain  nift  hartlware  data  are  specifietl  by  tlie  establishment  of  sections  and  candidates.  A 
st'ction  IS  a particular  type  of  hanlwarc  such  us  airframe,  propulsion,  ordinance,  UlIF  ruilio, 
inertial  navigation  system,  etc.  Within  each  section  the  user  can  spwify’  several  candiilates. 
In  the  section  calUxl  inertial  navigation  systems,  there  could  Ix'  an  LN-15,  LN-12,  lNS-61, 
etc.,  reflecting  spivific  inertial  navigation  systems.  The  user  usually  has  complete  flexibility 
to  aggregate  or  di.saggri'gate  actual  black  boxes  into  equipment  elements  by  defining  the 
necessary  candidates  for  each  section  uiul  crtxiting  the  apfiropriate  states  and  mixle 
requirements  under  the  Aepdeck  command.  To  define  a candidate,  values  are  entennl  for 
the  data  item  associattxl  with  Uie  section. 

Following  is  a list  of  the  standanl  data  items  associated  with  ever>’  stxdion  in  the 
air-to-ground  program: 


A 


1.  MTBF  Mean  time  between  failurt's  basetl  on  flight  hours, 

2.  MTBMA  Mean  time  between  unscheduled  maintenance  actions, 

3.  OFR  Operational  hours  per  flight  hour, 

4.  PV  Vulnerability  factor, 

5.  NR  Numoer  of  redundant  boxes, 

6.  MTTR  Mean  time  to  repair, 

7.  PR  Probability  the  box  will  be  replaced, 

8.  PA  Probability  the  replacement  box  is  available, 

9.  PU  Probability  of  undetected  failun\ 

10.  PP'  Probability  of  fals*>  failure, 

11.  AC  Acquisition  cost,  and 

12.  UMC  Cost  per  unscheduled  maintenance  action. 
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Two  sections  have  additional  data  items  which  reflect  performance  data  unique  to  those 
sections.  (See  equipment  subsection  titled  special  sections).  In  general,  however,  the  above 
items  relating  to  hardware  reliability  and  cost  are  the  only  items  associated  with  each 
section.  The  first  two  digits  of  the  standard  Air  Force  work  unit  code  (WUC)  identify  a 
section. 

A candidate  cannot  be  created  unless  the  section  with  which  it  is  to  be  associated  has 
been  created  previously.  The  following  information  is  required  for  each  candidate; 

1.  Name  of  the  candidate, 

2.  Number  of  the  section  with  which  it  is  associated,  and 

3.  Values  for  the  data  items. 

The  following  six  data  items  are  associated  with  each  section  in  the  air-to-air  program: 

1.  Mean  time  between  failures, 

2.  Mean  time  to  replace, 

3.  Repair  time, 

4.  Mean  time  between  maintenance  actions, 

5.  Warmup  time,  and 

6.  Vulnerability  factor. 

Several  sections  require  additional  data  items  which  are  unique  to  those  sections. 

The  data  items  which  are  applicable  to  a candidate  were  specified  when  the  section  was 
created.  Once  the  appropriate  section  has  been  identified,  the  user  can  obtain  a listing  of  the 
data  items  to  determine  the  data  required. 

The  following  paragraphs  briefly  describe  existing  special  sections  resident  in  AEP. 

2.2.3.3.1  Special  air-to-ground  sections 

2.2.3.3.1.1  Airframe  Section.  This  section  has  extra  items  used  to  define  aircraft  data 
required  to  simulate  the  vehicle  equations  of  motion.  Several  of  the  aerodynamic  derivatives 
are  a function  of  mach  number.  The  user  can  enter  up  to  four  values  which  the  program  uses 
to  develop  the  continuous  curve  of  variable  versus  mach  number.  The  mach  numbers  for  the 
four  entries  are:  (1)  takeoff— Mach  2,  3,  (2)  subsonic— mach  0.9,  (3)  transonic— mach  1,  0, 
and  (4)  supersonic— mach  1,  1.  If  the  aircraft  does  not  operate  above  mach  0.9,  then  the 


transonic  and  supersonic  values  net*d  not  be  entered.  However,  the  user  should  be  careful 
that  the  flight  profile  does  not  inadvertently  cause  the  aircraft  to  enter  this  flight  regime. 

For  a development  of  the  equations  of  motion  and  more  detailed  definition  of  the  data 
requirwl,  see  AFAL-TR-73-l  l,  Pages  10-17.  In  addition,  volume  II  of  that  report  (classifitnl 
confidential)  contains  an  uncla.ssified  example  of  a development  of  the  requirwl  data  for  an 


2. 2. 3.3. 1.2  Propulsion  Section.  This  section  contains  extra  items  uswl  to  enter  data 
reganling  engine  characteristics.  There  are  -1  items  over  and  above  the  standarrl  12  items  that 
must  be  specified.  These  are: 

1.  Militarv'  specific  impulse  (hr)— this  item  is  usikI  to  calculate  fuel  consumption  for 
normal  throttle  settings; 

2.  Maximum  .specific  impulse  (hr)— this  item  is  used  to  calculate  fuel  consumption 
when  the  afterburner  is  used; 

3.  Military  thrust  (lb)— maximum  thrust  without  the  use  of  afterburner;  idle  thrust  is 
assumed  to  be  20  percent  of  this  value;  and 

•1.  Maximum  thrust  (lb>— maximum  thrust  with  afterburner;  if  the  aircraft  does  not 
have  an  afterburner,  items  2 and  4 above  should  be  the  same  as  1 and  3,  respectively. 

2.2.3.3.2  Special  air-to-air  sections. 

2. 2. 3. 3. 2.1  Airframe  Section.  The  first  section  is  utilized  to  define  the  aircraft  data 
required  to  simulate  the  vehicle  equations  of  motion.  Several  of  the  aerodynamic  derivatives 
are  a function  of  mach  number.  The  user  can  enter  up  to  four  values  which  the  program  uses 
to  develop  the  continuous  curve  of  variable  of  interest  versus  mach  numl>er.  The  mach 
numliers  for  the  four  entries  are:  (1)  takeoff— mach  0.3,  (2)  subsonu — mach  0.9,  (3) 
transonic— mach  1.0,  and  (4)  supersonic— mach  1.1.  If  the  aircraft  does  not  operate  above 
mach  0.9,  then  the  transonic  and  supersonic  values  need  not  be  entered.  However,  the  user 
should  be  careful  that  the  flight  profile  does  not  inadvertently  cause  the  aircraft  to  enter 
this  flight  regime. 

2.2.3.3.2.2  Propulsion  Section.  The  second  section  is  utilized  to  enter  data  regarding 
engine  characteristics.  Four  items  over  and  above  the  standard  six  items  must  be  spei'ified. 
These  are: 

1.  Military  specific  impulse  (hr)— this  item  is  used  to  calculate  fuel  consumption  for 
normal  throttle  settings; 
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2.  Maximum  specific  unpulse  (hr)— this  item  is  used  to  calculate  fuel  consumption 
when  the  afterburner  is  used; 

3.  Military  thrust  (lb)— maximum  thrust  without  the  use  of  afterburner;  idle  thrust  is 
assumed  to  be  20  percent  of  this  value;  and 

4.  Maximum  thrust  (lb)— maximum  thrust  with  afterburner. 

If  the  aircraft  does  not  have  an  afterburner,  Items  two  and  four  above  should  be  the 
same  as  one  and  three,  respectively. 

2.2.3.3.2.3  Radar  Section.  This  section  is  reserved  for  pulse  Doppler  radar.  The 
peculiar  data  items  are: 

1.  Peak  transmitted  power  (W), 

2.  Pulse  repetition  frequency  (Hi), 

3.  High  (1)  or  low  (2)  PRF  (not  presently  used), 

4.  Transmit  duty  cycle, 

5.  Receive  duty  cycle, 

6.  Antenna  gain  (db), 

7.  Wavelength  (m), 

8.  Bandwidth  (Hz), 

9.  Noise  figure  (dB), 

10.  System  losses  (dB), 

11.  Sidelobe  gain  (dB),  and 

12.  False  alarm  number. 

2.2.3.3.2.4  Radar  Main  Beam  Clutter  Filter  Section.  This  section  is  reserved  for  the 
radar  main  beam  clutter  filter  data.  Data  are  entered  as  filter  gain  (dB)  versus  the  difference 
between  range  rate  and  clutter  velocity  (FPS).  Up  to  four  values  of  gain  can  be  entered  (all 
negative  dB)  for  four  values  of  velocity  difference  (must  be  positive  monotone  increasing). 

2.2.3.3.2.5  IR  Detector  Section.  This  section  is  reserved  for  entering  the  response 
versus  wavelength  (micron).  Up  to  eight  values  of  response  can  be  entered.  The  units  of 
detectivity  are  CM*HZ**.5/W.  The  logarithm  (base  10)  of  detectivity  is  entered.  The  data 
couples  should  be  entered  in  increasing  values  of  wavelength. 

2.2.3.3.2.6  IR  Optics  Section.  This  section  is  reserved  for  entering  the  IR  optics 
transmissitivity  versus  wavelength  (p).  Up  to  four  data  couples  can  be  entered  in  increasing 
values  of  wavelength.  The  transmissitivity  can  take  on  values  between  zero  and  one. 
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2,3  GASP  IV 

2.3.1  Models,  Systems,  and  Simulations 

.A  simulation  lan>;uano  provides  the  strvioture  and  ti>rminoio>i>’  to  faoilitato  tlu*  huildini; 
of  simulations,  (l.ASP  1\'  is  suoli  a computer  lancuane;  it  helps  the  user  to  build  computer 
simulation  piM^jrams  that  can  be  both  the  minlel  of  the  system  and  the  analysis  vehicle.  Thus 
this  proiiram  can  be  ciinsiden'il  a model  of  a system  and  a generator  of  statistical  data  about 
the  model  of  the  system. 

('i.ASP  IV  enables  statistical  experiments  to  be  conducted,  but  it  does  not  deal  with 
actual  experimental  design.  (l.ASr  IV  can  make  simulation  economical  and  twhnically 
feasible,  but  it  does  not  pnwkle  information  that  makes  the  "simulate  or  not"  division  any 
easier 

2. 3. 1.1  Features 

.\.s  a proxTammini;  lan(,nia»;e.  tl.ASl'  IV  s'ives  the  computer  proiinimmer  a set  of 
FOR  I’H.AN  St. dements  designed  to  carry  out  the  most  important  functions  in  simulation 
proKrammiiiK  MiHlelinis  ciuicepts  are  translatiHl  by  (l.ASl’  l\’  into  FdK  I'K.AN  routines  that 
can  be  easily  useil  t'lASl’  IV  has  five  distinct  features  that  make  it  particularly  attractive  as  a 
simulation  lanituaite 


I 


ISO 


I 


> 


1.  CiASP  IV  is  FORTRAN  hnswl  and  rtiiuirt's  no  sopurato  rompilint;  system. 

2.  OASP  IV  is  modular  and  can  he  made  to  fit  on  all  machines  that  use  a FORTRAN 
IV  compiler. 

3.  G.\SP  IV  is  easy  to  learn  siitce  the  host  pro({nunminn  lanjtuajte,  FORTRAN  IV,  is 
usually  known,  and  only  the  simulation  concepts  need  1h»  mustered. 

■1.  G.'XSP  IV  can  be  used  for  discrete,  continuous,  and  combined  modelinu. 

5.  G.ASP  IV  is  easily  modified  and  exteiKlwl  to  meet  the  netnls  of  particular 
applications. 

2.3. 1.2  Discrete,  Continuous,  and  Combined  Simulation 

Simulation  is  divided  into  two  categories:  discn-te  change  and  continuous  change.  These 
terms  describe  the  model,  not  the  real  system.  In  fact,  it  may  be  possible  to  model  the  same 
system  with  either  a discrt'U'  change  (hen'ufter  r»‘ferr»'d  to  simply  as  discrete)  or  a 
continuous  change  (continuous)  rntnlel.  GASP  IV  is  designed  to  accommtxlute  both 
I categories  of  mixlels,  separately  or  combined.  In  most  simulations,  time  is  the  major 

' independent  variable.  Other  variables  included  in  a simulation  an'  functions  of  time  and  lU'e 

^ the  dependent  variahle.s.  l'h«‘  adjei'tives  di.scn'b'  and  continuous  refer  to  the  In'havior  of  the 

I dependent  variables. 

1 

! Discrete  simulation  occurs  when  the  dependent  variables  of  the  model  change  discn'tely 

at  specified  points  in  simulaU'd  time.  The  time  variable  may  1h'  either  continuous  or  discn'te 
in  such  a model,  depending  on  whetlier  the  discn'U'  changes  in  the  dependent  variables  can 
occur  at  any  point  in  time  or  only  at  specified  points.  Variable  time  incrt'ment  (including 
next-event)  procedures  result  in  a continuous  time  variable,  whereas  fixetl  time  incrt>ment 
procedures  art'  normally  discrete  in  time.  GASP  IV  is  a discrt'te  simulation  language; 
however,  it  is  ni'cessary  to  rt'cognize  Uiat  a digital  computer  is  technically  discrete  in  its 
operation.  As  a practical  matter,  however,  any  variable  whose  possible  values  im*  limitt'tl 
only  by  the  inhert'nt  capabilities  of  a computer  is  considered  continuous. 

In  continuous  simulation,  the  dependent  variables  of  the  model  may  change 
continuously  over  simulated  time.  A continuous  motiel  may  lie  eitlier  continuous  or  discrt'te 
in  time,  depending  on  whether  the  values  of  the  dependent  variables  lurt'  available  at  any 
(Hiint  in  simulattni  time  or  only  at  sptH'ifit'd  {X}ints  in  simulated  time. 

* In  combinetl  simulation  the  dependent  viu'iables  of  a model  may  change  discretely. 

continuou.sly.  or  continuously  with  discrt'te  jumps  superimpostnl.  The  time  viuiable  may  Ix' 
discrt'te  or  continuous. 
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CiASP  IV  is  u laiiKuajje  that  can  In?  us«i  for  discrete,  continuous,  or  coml)ined 
simulation.  In  GASP  IV,  the  most  imporUint  characteristics  of  comhineti  simulation,  which 
arise  from  the  interaction  lietween  discretely  and  continuously  clianttinj;  variables,  are  easily 
modek'd.  In  ^teneral,  this  interaction  takes  one  of  three  forms.  First,  discnde  chanj;es  may  Ix' 
appluxl  to  "continuous"  variables.  Second,  achieving  specified  conditions  for  a state  variable 
may  cause  an  event  to  occur  or  to  be  scheduled.  Third,  the  functional  description  of 
continuous  variables  may  be  changiHi  discretely. 

2.3.2  GASP  IV  Philosophy 

The  philosophical  basis  for  the  design  of  GASP  IV  is  the  concept  of  modeling  a system 
in  two  dimensions:  the  time  dimension  and  the  slate-space  dimension.  Fundamental  to 
building  a GASP  IV  simulation  model  is  the  decomposition  of  time  and  Uie  state  space  into 
manageable  elements.  The  decomposition  in  the  time  dimension  involves  the  defining  of 
events  and  potential  changes  to  the  system  when  an  event  occurs.  The  GASP  I\’  philosophy 
! requires  that  the  user  specify  the  causal  mechanisms  by  which  events  can  occur,  but  relieves 

* him  completely  of  the  net'd  for  sequencing  the  events.  Thus  the  user  must  only  define  the 

] mathematical-logical  relations  that  transpire  at  an  event  occurrence,  and  he  is  not  required 

' to  mcxiel  the  timing  of  events  during  a simulation.  This  decomposition  of  the  time  axis  into 

points  at  which  events  could  occur  is  a huge  reduction  in  the  size  of  the  nuxleling  effort. 

In  the  state-space  dimension  GASP  IV  pivsumes  that  a system  model  can  be 
decomposed  into  its  entities,  which  an>  described  by  attributes.  These  tm>  further  classified 
as  discrete  or  continuous.  The  use  of  the  adjectives  “discrete"  and  "continuous”  is 
motivated  by  their  use  in  the  definitions  of  discrete  and  continuous  simulation.  More 
descriptive  adjectives  would  be  static  and  dynamic.  The  value  of  a discrete  attribute  remains 
constant  between  event  times.  The  value  of  a continuous  attribute  may  change  Iretween 
events  according  to  a prescribed  dynamic  behavior.  Because  of  tlie  special  nature  of 
continuous  attributes  and  the  need  for  the  user  to  model  their  dynamic  lx‘havior,  they  art* 
referrtKl  to  as  state  variables.  Special  storage  arrays  are  provided  in  GASP  IV  for  storing 
values  of  state  variables  and,  also,  if  required,  their  derivatives  and  immediate  past  values.  To 
avoid  confusion,  the  word  “attribute"  is  used  to  refer  only  to  a discrete  attribute. 

GASP  IV  specifies  that  the  status  of  a system  be  descrilied  in  terms  of  a set  of  entities, 
their  associated  attributes,  and  state  variables.  The  GASP  IV  simulation  philosophy  is  that  a 
dynamic  simulation  can  be  obtained  by  modeling  the  events  of  the  system  and  by  advancing 
time  from  one  event  to  the  next.  This  philosophy  presumes  a broader  definition  of  event 
than  has  normally  been  used  in  discrete-event  languages; 
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An  event  occurs  at  any  (Joint  in  time  beyond  which  the  status  of  a system 
cannot  be  projecte^^l  with  certainty. 

hVents  usually  cause  changes  in  the  status  of  the  system  or  in  the  equations  defining  the 
state  variables  of  the  system.  However,  this  definition  does  not  ne^'essarily  relate  an  event  to 
any  change,  either  discrete  or  continuous,  in  the  status  of  a system.  Events  could  ocvur  at 
dei'ision  points  whert>  the  decision  is  not  lo  change  the  status  of  the  system.  Conversely,  tiie 
aln'ce  definition  allows  the  system  status  to  change  continuously  without  an  event 
iKcurring,  as  long  as  the  change  has  been  presi’rihiHl  in  a well-defimxl  manner. 

In  G.\SP  IV  it  is  ust'ful  to  descrilH'  wents  in  terms  of  the  mechanism  by  which  they  are 
schtH.luh'd.  Those  that  occur  at  a specifiwl  projectetl  point  in  time  are  referrt*d  to  as 
time-events.  They  lu-e  commonly  used  in  conjunction  with  "next  event”  simulation.  Those 
tliat  occur  when  the  system  rt>aches  a particular  state  are  calUnl  state-events.  Unlike 
time-events,  they  are  not  scheduled  in  the  futurr'  hut  occur  when  sUite  viu-iables  met't 
presi  rilH'd  conditions.  In  G.\SP  IV.  state-events  can  initiate  time-events  and  time-events  can 
initiate  state-events. 

The  behavior  of  a system  model  is  simulattHl  by  comjiuting  the  values  of  the  attributes 
at  event  times.  I'he  time  step  incr»'ment  is  automatically  determined  by  G.ASP  IV,  based  on 
the  (H|uation  form  for  the  state  variables,  the  time  of  the  next  event,  and  accuracy  and 
output  rtxiuirements. 

When  an  event  occurs,  it  can  change  system  status  in  three  ways;  by  altering  the  value 
of  state  viuiables  or  the  attributes  of  the  entities;  by  altering  n'lationships  that  exist  among 
entities  or  state  variables;  and/or  by  changing  the  number  of  entities  pn'sent.  Methods  art' 
available  in  G.ASP  IV  for  lU'complishing  each  type  of  change.  .Any  of  these  changes  can 
n'sult  from  the  occurrence  of  an  event.  Between  event  times,  only  the  values  of  the  state 
variables  can  change. 

.At  each  tinu'-step,  the  state  variables  luv  evaluated  to  determine  if  the  conditions 
prest'ribing  a state-event  have  occurretl.  If  a state-event  was  (jassed,  the  step  size  was  too 
large  and  is  rtnluceil.  If  a staU'-event  occurs,  the  model  status  is  updated  awording  to  the 
user’s  state-event  subroutine.  Step  size  is  automatically  set  so  that  no  time-event  will  occur 
within  a step.  This  is  accomplished  by  setting  the  step  size  so  that  the  time-event  ends  the 
step. 

Since  timi'-events  an’  sc-hedulwl  happenings,  certain  attributes  are  associated  with  them. 
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At  thf  minimum,  a time-event  must  have  attributes  that  define  its  time  of  occurrence  and  its 
type.  If  the  time  evt.it  is  associated  with  an  entity,  either  the  attriliutes  of  tliat  entity  must 
Ih'  associatetl  with  it  or  the  event  must  lie  aide  to  refer  to  the  attriliutes  of  the  entity.  For 
example,  if  there  is  an  end-of-service  event  for  an  item,  the  attributes  for  Uiat  item  must  in 
some  way  be  as.suciated  witlt  the  event. 

2.3,2, 1 Data  Storage  and  Timing  Requirements 


In  (5ASP  IV'  a system’s  file-entity-attribute  structure  is  established  by  data  declarations. 
Kntities  are  represented  by  vwtors  and  matrices,  the  elements  of  which  are  storixi  and 
represent  attribute  data. 

The  membership  of  entities  in  jjroups  (sudi  as  a waiting  line)  is  changeable,  and  the  data 
that  express  them  are  stored  differently.  They  are  stored  in  computer  lists  calUxl  files.  A 
single  array  NSET  is  used  to  store  all  files.  Special  routines,  such  as  FILEM  (to  put  an  entity 
in  a file)  and  RMOVE  (to  take  an  entity  from  a file),  are  part  of  the  G.VSI*  IV  language. 

Entities,  attributes,  staU>  variables,  and  file  membersliips  comprise  the  static  structure  of 
a simulation  model.  They  describe  the  state  of  a system  model  but  not  the  operation  of  the 
system.  The  latter  depends  on  event  definitions  and  the  equations  defining  the  Ixdiavior  of 
the  state  variables. 

The  key  to  event  simulation  is  the  ability  to  organize  events  so  that  they  are  executed 
within  the  computer  in  an  order  corresponding  to  that  which  would  occur  in  the  real 
system.  This  preserves  the  time  relationship  between  simulated  and  rt>al  events.  Ordinary 
programming  languages  are  unsuitable  for  this  task  bt'cause  they  operate  in  a strictly 
stHiuential  manner;  there  is  no  way  to  tell  a FORTRAN  program  to  "do  something  later" 
without  building  special  subprograms.  GASP  IV  provides  these  subprograms. 

2.3.2.2  Method  of  Simulation  Programming 

Every  GASP  IV  simulation  model  consists  of:  (1)  a set  of  event  programs  or  state 
variable  equations,  or  both,  that  describe  a system’s  dynamic  behavior,  (2)  lists  and  matrices 
that  store  information,  (3)  an  executive  routine  that  directs  the  flow  of  information  and 
control  within  the  model,  and  (4)  support  routines.  These  form  an  operating  computer 
progriun  whose  performance  reflects  that  of  a simulated  system.  .-V  GASP  IV  program  is 
made  up  of  subprograms  linktxl  together  by  an  executive  routine  that  organizes  and  controls 
the  performance  of  the  subprograms. 
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Simulation  programs  contain  routines  for  reading  input  data,  performing  record  keeping 
tasks,  advancing  time,  updating  system  status,  producing  reports  of  the  simulated  system’s 
behavior,  and  so  forth.  A simulation  program  is  said  to  be  in  a particular  mode  of  operation 
when  it  is  performing  the  corresponding  function,  for  example,  the  input  mode  or  the 
simulation  mode.  A mode  can,  when  necessary,  call  upon  many  separate  programs,  each 
performing  a task  related  to  the  general  function  of  the  mode. 

2.3.2.3  GASP  IV  Functional  Capabilities 

GASP  IV  is  oi^anized  to  provide  eight  specific  functional  capabUities; 

1.  Event  control. 

2.  State  variable  updating  using  integration  if  necessary. 

3.  Information  storage  and  retrieval. 

4.  System  state  initialization. 

5.  System  performance  data  collection. 

6.  Program  monitoring  and  event  reporting. 

7.  Statistical  computations  and  report  generation. 

8.  Random  deviate  generation. 

Four  of  these  capabilities,  (1),  (2),  (4),  and  (6),  are  primary  functions.  At  the  time  a 
program  is  engaged  in  one  of  them  it  is  not  performing  any  of  the  others.  The  remaining 
four,  (3),  (5),  (7),  and  (8),  are  support  oriented;  they  provide  a fundamental  computational 
or  data  processing  capability  that  is  not  control  oriented. 

The  four  primary  capabilities  constitute  the  basic  modes  of  GASP  IV,  which  are  shown 
in  Figure  2. 3. 2. 3-1. 

Two  forms  of  program  control  are  required.  One  directs  the  program  into  its  various 
modes:  initialization,  state  variable  updating,  monitoring,  and  so  forth.  The  other  operates 
within  the  simulation  model  and  sequences  the  execution  of  event  routines.  In  GASP  IV, 
the  first  function  is  called  the  executive  function  and  the  second  is  called  the  event  selection 
function. 

The  executive  function  is  computationally  and  logically  oriented;  it  switches  from  mode 
to  mode  as  the  logic  of  a program  dictates.  It  also  updates  state  variables  over  time  using  a 
step-evaluate-step  procedure.  At  each  step,  the  state  variables  are  updated  and  their  values 
are  checked  against  the  conditions  defining  state-events.  The  event-selection  function  is 
time-oriented;  it  switches  to  an  event  when  one  occurs. 


Figutt  2.3.2.3't.  Baiic  modtt  ol  GASP  IV  control. 


Ailtlilioitnl  siiiMilatioH  floxilnlily  oait  l>o  ai’hir'vtnl  l>y  ilofmiitu  i'ot\trv>l  ovonts  in  aditition 
lo  systr'ni  lu'tivity  I'vi'iils.  Thoso  ovonts  art'  timo  nrioiUt'd  instriu'timis  (ti  tlio  oxocutivo  that 
allow  miHlt*  .switi'hinjt  to  In'  |H'rft>nntHl  on  a timo  anil  a lo>{U'  Uisis.  (.)no  fan  sflu'dvilf  an 
I'vi'nt  to  "nil  into  output  moilo’’  wlu'u  tho  simulator  flock  rt'aclifs  1000  hours  as  well  as 
when  demand  c.xffixls  100  units. 

Thf  form  of  i>rKani7.ation  usetl  in  (IASI’  IV  is  hioriux'hical;  thore  arc  two  levels  of 
control,  aiul  each  level  has  authority  over  its  suhonlinate  levels. 

The  highest  level  of  program  conirt)!,  Uie  executive  level,  determines  what  the  proKTiim 
must  do  at  each  point  in  simulattxl  time  atul  directs  control  ti'  the  appropriate  motle  to 
IH'rform  the  selin  tt'd  task.  Control  pusses  from  executive  level  to  mode  and  hack  u»;ain. 
Control  is  maintaintxl  within  a motle  until  all  computations  ami  evaluations  iH'rtinent  to 
that  mtnle  havt*  he«*n  matle.  'I'he  sinpiencinK  of  the  computations  and  evaluations  is 
accomplisluHl  ns  part  of  the  function  desiuntHl  into  the  subproitrams  of  the  nuHte. 


One  of  the  most  important  uses  of  simulation  is  to  investigate  the  effect  of  changes  in  a 
system  on  sehvttxl  measures  tif  system  tH'rformance.  This  is  tr\ie  whether  a simulation  is 
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being  used  for  evaluation  or  design.  The  “hierarchical  control-mode-data  pool”  concepts 
provide  the  needed  flexibility  in  design  and  adaptation,  since  changes  in  simulation  models 
usually  require  changes  in  input  data,  system  elements,  or  event  logic.  A modular  structure 
allows  event  logic  to  be  changed  quite  simply,  because  each  event  is  a separate  subprogram. 
A data  pool  allows  changes  made  in  data  inputs  to  be  communicated  throughout  an  entire 
simulation  model  by  a change  in  a single  data  input.  The  preparation  of  reports  summarizing 
the  results  of  simulation  runs  is  simplified  by  utilizing  standard  report  programs  that  obtain 
their  information  from  the  common  data  pool.  Perhaps  most  important  of  all,  model 
debugging  is  simplified  by  providing  access  points  at  which  program  results  can  be  sampled 
without  interfering  with  the  logic  of  particular  events. 

2.3.3  GASP  IV  Definitions  and  Procedures 

A simulation  program  written  in  GASP  IV  consists  of  two  parts:  a user  part  and  a GASP 
I'/  part.  The  user  part  contains  subprograms  tor  initialization  (the  main  program  and 
subroutine  INTLC);  equations  for  state  variables  and  conditions  defining  state-events 
(subroutines  STATE  and  SCOND);  event  code  definitions  (subroutine  EVNTS);  event 
processing  (subroutines  called  by  EVNTS);  and  special  data  collection  and  reporting 
procedures  (subroutines  SSAVE,  OTPUT,  and  UERR).  The  GASP  IV  part  contains 
subprograms  that  provide  for  the  following  functions:  the  executive  or  mode  controller 
(subroutine  GASP),  data  and  event  initialization  (subroutine  DATIN),  data  storage  and 
retrieval,  data  collection,  statistics  computation  and  reporting,  monitoring  and  error 
reporting,  random  deviate  generation,  and  miscellaneous  support. 

The  GASP  IV  function  of  the  status  advance  includes  the  sequencing  of  time-events, 
identification  of  state-events,  and  state  variable  integration  if  needed.  It  is  the  heart  of  the 
executive  process.  The  main  program  initializes  the  non-GASP  variables  that  are  to  remain 
constant  for  all  simulation  runs.  Subroutine  GASP  is  then  called  from  the  main  program. 
The  general  layout  of  the  main  program  is  shown  in  Figure  2. 3. 3-1.  Subroutine  G ASP’s  first 
action  is  to  call  subroutine  DATIN,  which  initializes  all  GASP  IV  variables  either  through 
arithmetic  statements  or  the  reading  of  data  cards.  Either  data  cards  or  a programming  code 
can  be  used  to  establish  the  initial  events  and  entities  for  the  simulation.  Subroutine  DATIN 
calls  the  user  generated  subroutine  INTLC,  which  is  used  to  initialize  non-GASP  variables  at 
the  start  of  each  run.  Through  the  use  of  subroutine  INTLC  the  user  can  perform  sequential 
simulations  with  changes  in  the  non-GASP  variables.  Initialization  of  state  variables  is 
accomplished  by  a call  to  subroutine  STATE.  This  completes  the  initialization  phase  of  the 
simulation. 


187 


I * 


r 


f 


I ' 


I 

( 

I 

f 


1 


C MAIN  PROGRAM 

DIMENSION  NSET  (NNSET) 

C NNSET  to  be  specified 

COMMON  (GASP  variables) 

COMMON  (non-GASP  variables.  This  must  be  a named 
COMMON  Block) 

EQUIVALENCE  (NSET(l),  QSET(1)) 

C Initialusation  of  non-GASP  variables 

C Initialize  Card  Reader  Value,  NCRDR  and  Printer  Value, 
C NPRNT. 

CALL  GASP 

C If  more  runs  are  desired,  insert  GO  TO  statement 

C to  either  reinitialize  non-GASP  variables  or 

C to  CALL  GASP  again 

STOP 
END 


Fifurt  2.3.3-1.  Layout  of  main  program. 


During  a simulation  run,  subroutine  GASP  determines  if  a time  advance  by  a step  or  to 
the  next  event  should  be  made.  If  the  simulation  only  involves  time-events,  TNOW  is  set 
wjual  to  the  time  of  the  next  event.  If  only  a continuous  simulation  is  Iwing  performed, 
I'NGW  is  advancwl  to  the  time  at  which  the  next  evaluation  of  the  state  variables  is  to  be 
made.  If  a combined  simulation  is  being  perfornuHl,  the  time  advance  occurs  by  steps,  with 
the  step  size  adjusted  when  necessary  to  end  at  an  event.  A run  can  1h*  completed  either  l>y 
setting  a time  for  completion  or  l)y  having  an  end-of-simulation  event.  If  a run  is  not 
completed,  the  clock  for  the  simulation,  as  represented  by  the  variable  TNOW,  is  advancwl. 

In  continuous  and  combiuetl  simulations,  the  updating  of  the  state  variables  is 
performed  in  subroutine  STATK.  'Fhe  vectors  SS(  •)  and  Dl)  ('lure  usetl  to  define  the  state 
variable  values  and  their  derivatives,  respectively.  The  u.ser  must  code  subroutine  ST.Vl'K  in 
a manner  that  permits  the  calculation  of  SS(‘)  or  Dl)(‘).  Once  the  sUite  variabh's  are 
updated,  their  values  are  checked  against  user  prescribeil  conditions  that  define  stati>-events 
in  subroutine  SCOND.  if  no  state-event  has  occurred,  time  is  acivancetl  again  by  subroutine 
GASP. 


If  time  has  advanced  to  a tune-event,  subroutine  G.\SP  otitains  the  attriluites  for  the 
event  liy  removing  the  first  event  stored  m file  1,  which  is  the  ev»*nt  file  or  <-alendar  of 
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evonts.  The  usor  written  siiltroutine  KVN’rS(lX)  is  ealUtl  to  lieeipher  the  event  it)cte, 
l\,  aiut  to  I .ill  the  api>ropriate  event  snlirontine. 

■A  eall  to  suhroiitine  KV'NTS  is  al.so  inaile  if  a state-event  oeeiirs.  In  tJiis  ea.se,  l.\  is  tlie 
•State-event  eode  iiuheatiiiK  that  a state-event  has  oeenireil. 

When  a simulation  run  is  eompleteil,  .subroutine  OTPl' T is  ealled.  Subroutine  tvri’l''r 
provides  the  user  wiUi  a ineehanism  to  make  final  ealeulations  for  the  simulation  run  and  to 
print  out  any  .spivifie  information  that  was  eolleeted  lUirinj;  the  nin.  Thus  tlie  eall  of 
subroutine  DTl’l'T  ean  be  usisl  as  an  end-of-simulation  event.  Followinn  a n*turn  from 
.subroutine  (Vri’l’T,  subroutine  ti.-\SI’  ealls  subroutine  SUMRY,  which  prints  out  tlie  final 
ti.ASI*  l\’  summary  rt'port,  includin^'  statistical  information,  table.s  of  state  variabh's,  and 
plots  of  state  variables.  The  user  can  al.so  .sutipri'ss  the  printint*  of  the  ti.-\Sl*  1\’  .summar>’ 
report.  Followinn  the  printinn  of  the  final  summary  report,  tests  are  made  to  determine  if 
other  simulation  runs  are  to  1h‘  made.  .-X  new  simulation  run  can  be  started  by  returnmu  to 
the  main  projjram  for  complete  reinitialization  or  to  subroutine  1).-\T1N  for  partial 
reinitialization.  If  another  run  is  to  be  made,  the  above-mentioniHl  proce.ss  is  repeated.  If  no 
further  nins  are  reijuirtvl,  tlie  simulation  projiram  is  terniinaliHl. 

2.3.3.1  An  Overview  of  Subroutine  GASP 

Figure  2.3.;i.l-l  pn'sents  a descriptive  flow  chart  of  subroutine  (J.ASr.  tl.ASl’  first  calls 
subroutine  l).-\  riN,  which  initializes  all  t5.-\SI’  IV  variables  either  directly  or  from  readin^ 
data  canis.  Initial  events  and  other  file  entries  can  al.so  be  establishiHl  by  DATIN.  Resides 
initialization,  D.ATIN  al.so  prints  out  the  values  of  Uie  input  data.  F.vents  to  occur  at  the 
beKinniiiK  of  the  simulation  an*  then  processt*d. 

.A  test  is  then  made  to  determine  if  the  simulation  involves  only  time-events,  that  is,  a 
discrete  simulation.  If  this  is  the  case,  a ne.\t  event  time  advance  is  1181*11  and  the  simulation 
procei*<l.s  from  time-event  to  time-event  until  a signal  is  niven  to  end  the  simulation.  The 
method  usihI  in  (i.-\SI’  IV  to  perform  the  next  event  portion  of  a simulation  involves  file  1. 
the  event  file  ii.sed  to  stem*  attributes  as.so<*iateil  with  events.  Since  events  must  U*  inserted 
in  the  file  and  removixl  from  it  in  chronological  onler,  it  is  tuvessary  to  have  routines  for 
thi*se  functions.  The  GASP  IV  subroutine  FILKM  puts  events  in  the  event  file  basinl  on  the 
time-of-event  attribute.  The  subroutine  RMOVK  removes  events  from  tfie  event  file.  Thus 
G.-\SP  IV  provides  an  information  storatte  and  retrieval  system  for  events. 

In  addition  to  the  calendar  of  events,  other  files  of  information  must  usually  be 
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maintained  during  simulation  runs.  All  files  are  stored  in  the  equivalenced  arrays 
NSET/QSET  and  are  processed  by  the  subroutines  FILEM  and  RMOVE. 

To  write  a discrete-event  simulation  program,  it  is  necessary  to  specify  the  changes  that 
occur  at  event  times,  and  the  future  events  that  are  generated  by  event  occurrences.  The 
user  writes  these  event  routines,  such  as  ARRIV  and  ESERV,  which  specify  what  happens  in 
the  simulation  model  when  these  events  occur. 

To  write  a continuous  simulation  program,  the  equations  governing  the  dynamics  of  the 
state  variables  must  be  defined,  and  state-event  conditions  must  l)e  specified  if  they  exist. 
For  a combined  discrete-continuous  simulation,  all  of  these  must  be  written.  GASP  IV  has 
been  designed  to  reduce,  as  much  as  possible,  the  amount  of  programming  necessary  beyond 
writing  the  event  and  state  variable  routines. 

If  the  simulation  involves  “continuous”  variables,  a step-evaluate-step  time  advance 
procedure  is  used.  The  step  size  is  variable  to  ensure  that  no  events  occur  within  the  step 
and  that  the  desired  accuracy  in  the  calculation  of  state  variables  is  maintained.  The 
accuracy  test  is  necessary  only  if  state  variables  are  described  in  terms  of  a derivative 
equation,  where  integration  is  required  to  obtain  state  variable  values.  To  ensure  that  a 
time-event  does  not  occur  within  a step,  the  step  size  is  automatically  adjusted  so  that  the 
time-event  occurs  at  the  end  of  the  step.  For  state-events  the  step  size  is  reduced  if  such  an 
event  occurs  within  the  step.  The  step  size  is  set  so  that  either  no  state-event  occurs  within  it 
(but  may  occur  at  the  end  of  the  step)  or  the  minimum  step  allowed  is  ustxl.  The  minimum 
step  allowed  is  specified  as  an  input  value  by  the  user.  A state-event  occurring  within  the 
minimum  step  size  is  considered  to  occur  at  the  end  of  the  step. 


The  conditions  for  a state-event  are  defined  by  the  user  and  would  normally  involve  a 
state  variable  achieving  a threshold  with  a prescribed  tolerance.  The  user  codes  these 
conditions  in  subroutine  SCOND.  The  equations  defining  the  state  variables  are  coded  in 
subroutine  STATE.  Subroutine  GASP  establishes  a step  size  by  which  it  attempts  to  advance 
time.  Subroutine  STATE  is  called  to  compute  the  values  of  the  state  variables  at  the  end  of 
the  proposed  step.  For  each  derivative  equation,  intermediate  calls  to  STATE  are  made  to 
perform  accuracy  checks  and  to  allow  derivative  equations  to  be  functions  of  the  state 
variables.  If  accuracy  is  not  met,  the  step  size  is  reduced  accordingly  and  the  process 
described  above  is  reinitiated. 


If  accuracy  conditions  are  met,  subroutine  SCOND  is  called  to  check  whether  a 


stale-ovent  occurred  within  the  step.  After  a return  from  SCOND,  GASP  performs  u test  on 
the  GASP  IV  vuriai)le,  ISEES,  to  determine  if  a state-event  has  l)een  passed  (ISKKS  < 0.),  if 
one  occurs  at  the  end  of  the  step  (ISKKS  > 0),  or  neither  of  Uiese  (ISKKS  = 0).  In  the  first 
case,  the  step  size  is  reduced  and  Uie  above- men tionetl  process  is  repeated.  In  the  latter  two 
cast's,  the  step  size  is  accepted  and  model  status,  including  TNOW,  is  updatt'd.  GASP  IV 
provides  the  subprogram  KROSS,  which  automatically  sets  ISKKS.  Function  KROSS  detects 
the  crossing  of  a variable  beyond  a threshold,  or  the  crossing  of  one  variable  by  another 
variable.  If  the  user  does  not  employ  KROSS,  he  must  set  ISKKS  before  returning  from 
subroutine  SCOND, 

If  the  step  ends  with  an  event,  this  is  processed  by  calling  subroutine  EVNTS,  which 
calls  the  appropriate  event  bastnl  on  the  event  code  of  the  event  occurring.  A check  is  tlien 
made  to  determine  if  the  simulation  is  to  be  ended.  If  not,  a next  step  is  processed. 

At  the  end  of  the  simulation  run,  a standard  GASP  IV  summary  report  is  prinUnl,  and 
tables  and  plots  of  the  state  variable  values  are  printed  as  requested. 

Table  2. 3. 3. 1-1  lists  definitions  for  the  G.\SP  IV  variables  Uiat  are  commonly  used  by 
the  GASP  IV  programmer.  Other  important  variables  an*  establislnnl  through  data  input  and 
these  are  defined  in  Table  2. 3. 5. 1-1. 

All  GASP  IV  variables,  with  the  exception  of  NSKT,  are  in  narntnl  COMMON  blocks. 
Blank  COMMON  is  only  used  for  the  array  NSET.  The  GASP  IV  user  must  not  use  blank 
COMMON  for  non-GASP  variables. 

2.3.3.2  Model  Status  Definition  and  Control 

The  status  of  a GASP  IV  simulation  model  is  definwl  in  terms  of  events,  entities  and 
their  attributes,  sUite  variables,  or  a combination  of  the  three.  Entity  definition  and  storage 
in  GASP  IV  is  accomplished  tlirough  the  use  of  the  file  storage  arrays  NSET/OSKP  and  file 
processing  routines.  Events  are  scheduled  to  occur  either  at  a futuit'  time  (a  tinu'-event)  or 
when  staU>  viuiables  meet  specified  conditions  (a  state-event).  I'ime-events  and  their 
associated  attribute's  are  stored  in  file  1 using  predecessor  and  suivessof  pointers.  Entities 
and  their  associateel  attributes  are  stored  in  file  2 through  file  NNFIL.  State  variables  and 
their  derivatives  are  stored  in  the  GASP  IV  arrays  SS(  •)  and  DD(  •). 

2.3.3.3  State  Variable  Definition 

The  GASP  IV  variables  SS(I),  SSL(I),  DD(1),  and  l)I)L(l)  arc  usetl  to  define  the  state 
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TABLE  2.3.3.1  1.  DEFINITIONS  OF  COMMONLY  USED  GASP  IV  VARIABLES 


ViriabI* 

Oafinition 

ATRIBdl 

Buftar  storaga  for  the  Ith  attribute  value  to  be  jtoied  in  or 
removed  from  QSET 

00(1) 

The  value  of  the  derivative  of  SSd)  at  TNOW 

OOL(I) 

The  value  of  the  derivative  of  SSd)  at  TTLAS 

DTFUL 

Full  step  tire 

OTNOW 

TNOWTTLAS 

IIEVT 

Coda  of  itata.eventi 

IINN(I) 

Prioritv  ranking  indicator  for  file  1 

ISEES 

Intarnal  indicator  that  a itate-event  ends  current-itep 

JEVNT 

Code  of  time-event  to  be  procened,  which  is  the  second 
attribute  of  an  event 

KKRNK(I) 

The  attribute  on  which  file  1 is  ranked 

LFLAG(I) 

State  condition  flags 

MFA 

Relative  address  of  the  fint  call  of  NSET/QSET  eveilable  for 
storing  a new  antry 

MFE(I) 

The  pointer  to  the  fint  entry  in  file  1 

MLE(I) 

The  pointer  to  the  last  antry  in  file  1 

MSTOP 

Indicator  for  specifying  method  of  ending  the  simulation 

NNATR 

Number  of  tttributes  per  entry 

NCROR 

Number  of  the  card  reader  (input  tape  number) 

NFLAG 

Number  of  state  condition  flags 

NPRNT 

Number  of  the  printer  (output  tape  number) 

NNQ(I) 

The  current  number  of  entries  in  fils  1 

NSETdl 

Integer  representation  of  filing  array;  used  for  pointers  only 

PPARMd,  J) 

Array  for  storing  paramatsr  values 

QSET(I) 

Real  valuad  raprasantation  of  the  fils  storage  area;  used  for  all 
attribute  values 

QQTIMd) 

Time  of  last  usa  of  file  1 

SSd) 

The  value  of  the  state  variable  SS(I)  at  TNOW 

SSLd) 

The  value  of  the  state  variable  SS(I)  at  TTLAS 

TTLAS 

The  last  time  at  which  an  event  could  have  occurred;  when  a 
step  advance  it  in  progress. 

TTLAS  it  the  time  at  which  Kceptable  values  of  SS(I) 
were  computed 

TNOW 

Current  time  of  simulation;  when  a step  advance  is  in  progress, 
TNOW  it  the  time  to  which  GASP  it  trying  to  edvance 

variables  and  their  derivatives  at  times  TNOW  and  TTLAS  when' 


TNOW 

TTLAS 


time  at  which  values  of  the  state  variables  are  being  computed. 

time  at  the  beginning  of  the  current  step  (the  time  at  which  the  values  for  the 

state  variables  wen’  last  accepted). 
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SS(  I ) = value  of  state  variable  1 at  time  TNOVV. 

SSL(l)  = value  of  state  variable  I at  time  TTLAS. 

DD(I)  = value  of  the  derivative  of  state  variable  I at  time  TNOW. 

DDL(  1)  = value  of  the  derivative  of  state  variable  I at  lime  TTLAS. 

The  equations  for  calculating  the  values  of  SS(1)  and  DDlD  must  be  written  by  the  user 
and  included  in  subroutine  STATE.  All  state  variables  are  in  GASP  IV  common  storage  and 
are  accessible  to  the  user  in  any  subprogram. 

2.3.3.4  Time  Advance  Procedures 

In  G.ASP  IV.  the  amount  by  which  simulated  time  is  advanced  depends  on  the  type  of 
simulation  being  performed  and  the  values  of  specific  variables  at  the  current  point  in  time. 

2. 3. 3.4.1  Discrete  simulation 

i 

1 In  a discrete  simulation,  time  is  advanced  from  one  event  to  the  next  event.  It  is 

j as.sumtHl  that  the  system  status  has  remained  constant  between  events. 

i 

2.3.3.4.2  Continuous  simulation 

For  a continuous  simulation,  the  maximum  step  size  prescribed  by  the  user  is  employtKl, 
unless  an  event  occurs  within  the  step.  Should  this  occur,  the  step  size  is  reduced,  if  the 
event  causes  a state  variable  to  cross  a threshold  beyond  allowable  tolerances.  The  step  size 
is  reduced  (typically  halved)  based  upon  allowable  error  specifications  introduced  by  the 
user.  When  all  state  variables  are  within  the  accuracy  specifications  to  a significant  extent, 
the  next  step  size  to  be  used  is  increased  by  an  integration  algorithm. 

It  is  obvious  that  the  time  advance  procedures  included  within  GASP  IV  involve  many 
variables  with  many  interactions  between  these  variables.  Subroutine  GASP  automatically 
advances  time  for  the  user  based  on  the  input  values  prescribed  for  the  minimum  step  size 
DTMIN,  the  maximum  step  size,  DTMAX,  and  the  increment  in  time  between  the  recording 
of  the  status  of  the  system,  DTSAV.  The  accuracy  requirements  of  absolute  error  value, 
AAERR,  and  relative  error  value,  RRERR,  as  well  as  the  value  of  the  derivative  of  the  state 
vaiiables  as  specified  by  the  user  also  determine  the  time  advance  procedures  used. 


I 


194 


r 


2.3.4  GASP  IV  Subprograms 

2.3.4.1  GASP  IV  Storage  Requirements  and  Limitations 

t'lASP  IV  usos  botli  nanuKi  and  b)ank  COMMON  storage.  Variables  are  stonnl  in 
CX^MMON  for  one  of  two  rt>asons:  (1)  to  make  Uieir  values  aeeessible  to  other  subpro>m>ms, 
or  (21  tt>  pivvent  their  undefinition  upon  execution  of  a RETURN  in  the  suhprojj’am  in 
which  they  »u-e  defiiietl. 

Blank  COMMON  Ls  only  ustnl  for  Uie  array,  NSET.  The  OASP  IV  user  must  not  use 
blank  COMMON  for  non-OASP  variables. 

NSET  is  placrnl  in  blai\k  CX>MMON  ston»(;e  so  that  it  can  lu'  dimensioiuHl  to  the  n>quirt‘d 
size  in  the  main  pit>({ram  and  nominally  dimensioneil  to  one  in  all  the  G.ASP  IV 
subprograms.  This  takes  advantatte  of  the  fact  that  the  size  of  blank  t OMMON  in  the 
1 various  subprograms  comprising  an  executable  progrtun  iuhhI  not  be  the  same.  Thus 

' pivcompiltHl  G.\SP  IV  subprograms  with  NSET  dimensioiuHl  at  one  can  Ih>  maintaiiuxi  on 

, the  computing  system,  and  the  dimension  of  NSE'P  can  lx>  set  in  the  user’s  main  program. 

Nanuxl  (X)MMON  is  us«h1  for  all  G.\SP  IV  variables  otl’er  than  NSET.  which  rt'quirt' 
COMMON  storage. 

The  organization  of  the  nanuHl  COMMON  blocks  wasdesigmxl  to  minimize  the  number 
of  COMMON  blocks  n'miinxl  in  the  user  subprcigrams.  .\  gross  descripition  of  the  variables 
for  each  common  block  is  given  below: 

1.  GtX)Ml  Variables  associated  with  discrete  simulations. 

2.  GtX)M2  Variables  associated  with  continuous  simulations. 

3.  GtX)M3  Variables  associated  with  a steji  time  advance  procwUire. 

4.  GtX4M4  N’ariables  associattnl  with  data  collection  and  reporting. 

5.  GfXIMb  Variables  associatinf  with  run  conditions  aiul  description. 

G.  GtX'lMG  Variables  associated  with  filing  .system  anil  statistical  storage  arrays. 

The  limitations  imposixl  by  array  size  and  the  variables  causing  the  limitation  an* 
(iresented  below.  .A  U.AT.A  statement  is  includiHl  in  subroutine  U.-VPIN,  which  sptvifies  the 
largest  value  for  each  limitation.  .A  chivk  is  made  in  subroutine  U.ATIN  to  ensure  that  these 
array  sizes  are  not  excix'diHl: 

1 . Numlx'r  of  state  variables  v 1 00, 
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2.  Nutnbfr  of  histotn^ujis  **1  25, 

;?.  Total  luimbor  of  cells  for  all  histojixams  *»  500, 

■I.  Number  of  viuiables  for  which  statistics  are  collected  < 25, 

5.  Number  of  variables  for  which  statistics  are  collected  over  time  ^ 25, 

(I  NumU'r  of  attributes  desc  ribing  an  event  •«.  25, 

7.  NumlH'r  of  files  >>*  100, 

8.  Number  of  parameter  sets  •«»  50, 

9 Number  of  plots  •>«  10, 

10.  Number  of  viuiables  per  plot  v 10, 

1 1.  Number  of  random  numlH*r  streams  0, 

1 2 Number  of  state  conditions  50, 

i;i.  Number  of  entries  per  file  limiti'd  only  by  available  core  storan»', 

2.3. 4.2  Functional  Breakdown  of  GASP  IV 

! The  functional  brrnikdown  of  the  tl.AST  IV  subprograms  is  shown  in  Table  2. 3. -1.2-1.  In 

,uldition  to  listing:  the  general  functions  included  in  simulation  programs.  Table  2. 3. -1.2-1 
I t-atej;ori/es  each  subproKnun  acconlinj;  to  whether  it  is  t'l.-VSp  IV  provuled  or  user  written, 

brief  descriptions  of  the  subroutines  follow  . 

2. 3.4.2. 1 Time  advance  and  status  update  (subroutine  GASP) 

The  ti.-\ST  IV  function  of  status  advance  includes  the  sequencinn  of  time-events, 
identification  of  state-events,  and  state  variable  inte>;ration  if  newled.  It  is  the  heart  of  the 
executive  process. 

Subroutine  C'i.\ST  is  the  ti.-\S!’  IV  executive  routine.  It  selects  the  appropriate  nunle  of 
control  and  calls  the  iUH'essai>’  subroutines  to  process  a simulation  from  initialization  of  the 
first  run  through  output  of  the  final  run.  Subroutine  Ci.-\ST  is  called  only  liy  the  user  written 
m;un  proirram,  and  control  is  not  returiuxl  to  the  main  pro>;ram  until  the  nniuestiHl  number 
of  runs  has  Ix'eii  completcxl. 

2.3.4.2.2  Initialization 

Initialization  of  variables  prior  to  the  exivution  of  a G.-XST  l\’  simulation  run  occurs  in 
pha.ses.  Some  variables  ar»'  initialized  during:  proia'am  compilation  by  n.-VT.-\  statements, 
t'thers  are  assimnxl  values  obtaintxl  directly  from  the  reading;  of  (!.\Sl’  l\’  input  data  carvls. 
Finally,  some  \ariables  are  assiumxl  initial  values  after  all  G.-\ST  IN’  input  data  cards  have 
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TABLE  2.3.4.M.  FUNCTIONAL  BREAKDOWN  OF  GASP  IV  AND  USER  SUBPROGRAMS 


I 

I 


Subprograms  Supporting  Function 

Function 

Provided  by  GASP  IV 

Provided  by  User 

Time  advance  and 
status  update 

Subroutine  GASP 

Subroutine  STATE 
Subroutine  SCONO 
Subroutine  EVNTS 
Event  subroutines 

Initialisation 

Subroutine  DATIN 
Subroutine  CLEAR 
Subroutine  SET 

Main  program 
Subroutine  INTLC 
Input  data 

Data  storage  and  retrieval 

Subroutine  FILEM 

Subroutine  RMOVE 
Subroutine  CANCL 
Subroutine  COPY 

Location  of  conditions 

and  entries 

Function  KROSS 

Function  NFIND 

Data  collection,  computation, 
and  reporting 

Subroutine  COLCT 
Subroutine  TIMST 

Subroutine  TIMSA 

Subroutine  HISTO 

Subroutine  GPLOT 
Subroutine  PRNTQ 

Subroutine  PR  NTS 
Subroutine  SUMRY 

Subroutine  SSAVE 
Subroutine  OTPUT 

Program  monitoring  and 
error  reporting 

Subroutine  MONTR 
Subroutine  ERROR 

Subroutine  UERR 

Miscellaneout  support 

Function  SUMO 

Function  PROOQ 

Function  GTABL 

Subroutine  GO  LAY 

Random  deviate  generation 

Function  GRAND 

Function  UNFRM 

Function  TRIAG 

Function  RNORM 

Function  RLOGN 

Function  ERLNG 

Function  GAMA 

Function  BETA 

Function  NPSSN 

Function  GAM 
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iHvn  roiul.  In  (lontTal,  oach  phaso  is  associaU'ci  witli  spocifu-  I'lemonls  of  the  exeeulahle 
projo-am.  DATA  sUUemenls  in  individual  suliprojtrams  assiKii  values  to  variables  local  to 
those  suhpixi(;nims.  The  main  program  must  initialize  two  GASP  IV  variables:  the  eanl 
reader  number,  NCKUR;  and  the  printer  number,  Nl’KN'P.  The  user  may  employ  the  main 
program  to  initialize  non-GASP  viuiables  prior  to  the  assumption  of  executive  control  by 
subroutine  GASP.  The  pn'cixling  multiple  runs  are  made.  The  last  phases  of  initialization  are 
controlled  by  subroutine  D.VITN;  they  are  discussed  in  conjunction  with  the  desc  ription  of 
that  subprogram. 

2.3. 4. 2. 2.1  Subroutine  DATIN.  This  subroutine  is  calUnl  by  subroutine  G.ASP,  and  it 
provides  for  the  seU*ctive  initialization  of  G.ASP  1\’  variables  through  four  mechanisms. 
Some  G.ASP  1\'  variables  are  initialized  to  sUindard  or  default  values;  some  are  assignt'd 
values  eciual  to  or  computed  from  G.ASP  IV  input  data;  some  are  assigned  values  derivwl 
from  the  user  providcH.!  subroutines  INTLC  and  ST.ATE;  and  some  are  assigned  values  (or 
left  unchanged)  from  a prc'vious  run.  Subroutine  n.ATlN  accomplishes  this  initialization  in 
the  proper  stxjuence  to  facilitate  either  single  or  multiple  runs. 

Suliroutiue  D.ATIN  aJ.so  perforim  error  checking  and  provides  a printout  (echo  check)  of 
the  input  data  that  may  be  selectively  supprt'ssed. 

Subroutine  D.ATIN  is  called  only  by  subroutine  G.ASP  and  only  during  the  initialization 
phase  of  a simulation  nin. 

2.3.4.2.2.2  Subroutine  CLEAR.  Subroutine  CLK.AR  is  ustxl  to  zero  out  the  storage 
arrays  that  collect  values  of  variables  to  be  reported  in  the  final  summary  report.  For 
example,  if  the  user  wants  to  calculate  statistics  bast'd  on  data  collected  after  time  1000,  the 
statement  CALL  CLEAR  inserted  into  the  program  at  time  1000  (possibly  through  a time 
event)  can  he  used  to  accomplish  this.  If  file  statistics  as  well  as  summarj'  statistics  are  to  be 
n'initializrtl,  this  can  be  accomplished  using  subroutine  MONTR. 

2.3.4.2.2.3  Subroutine  SET.  Subroutine  SET  initializes  the  filing  array  NSET  and  all 
variables  associated  with  the  filing  array.  This  includes  the  following  variables:  number  of 
entries  in  file  I.  NNQfl);  the  time  integrated  numl>er  of  entries  in  file  I,  EENQ(l);  the  second 
moment  of  the  time  integrated  number  of  entries  in  file  1,  VVNQ(I);  the  largest  number  of 
entries  that  have  been  in  file  I.  MMAXQ(l);  and  the  last  time  an  entry  was  either  filet!  or 
removed  from  file  1,  QQTlM(l).  A call  to  subroutine  SEl'  can  lx‘  activated  through  the  use 
of  the  G.ASP  IV  input  cards.  When  subroutine  SET  is  called,  all  events  and  entities  stored  in 
all  files  are  deleted  and  the  file  structure  is  reinitialized. 


198 


I 


2.3.4.2.3  Data  storage  arnl  retrieval 

rhc  data  storai^e  and  retrieval  subprograms  provide  the  mechanisms  through  which 
entries  with  their  associated  attributes  are  maintained.  In  GASP  IV,  entries  are  stored  in  a 
doubly  linked  list  maintained  in  the  filing  array  NSBT.  NSET  is  a one  dimensional  array  that 
is  etjuivalenced  to  the  one  dimensional  array  QSET,  which  is  in  COMMON  storage.  This 
enables  each  of  the  attribute  values  to  be  stored  as  a real  numlM?r  and  pointers  to  lx;  stored 
as  integers. 

Priority  in  a file  is  based  on  a ranking  attribute  and  a priority  method.  Any  attribute 
numlK'r  can  be  used  as  the  ranking  attribute  for  a file.  The  ranking  attribute  number  for  file 
I is  established  by  data  input  and  is  stored  as  the  GASP  IV  variable  KKRNK(l).  Four 
priority  codes  are  available  in  GASP  IV. 

1 . Ixi w-value-f irst  ( L V F ). 

2.  High-value-first  (HVF). 

3.  First-in-first-out  (FIFO). 

4.  Lj\st-in-first-out  (LIFO). 

2.3.4.2.3.1  Subroutine  FILEM  (IFILE).  This  subroutine  stores  the  attributes  of  an 
entry  in  a file,  updates  statistics  for  the  file,  and  maintains  the  time  for  the  next  discrete 
event  TPNEX  if  the  new  entry  is  an  event.  Subroutine  FILEM  is  a long  subroutine  since  it 
contains  the  coding  for  inserting  any  entry  into  any  file  under  any  of  the  four  priority 
methods. 

2.3.4.2.3.2  Subroutine  RMOVE.  To  remove  an  entry  from  a file,  subroutine  RMOVE  is 
used.  It  is  called  to  remove  the  entry  who.se  first  coll  number  is  NTRY(l)  from  file  IFILE. 
RMOVE  may  also  be  used  to  cancel  an  entry.  Subroutine  RMOVE  is  calk'd  by  subroutine 
GASP  to  process  the  next  time-event.  RMOVE  may  also  be  called  directly  by  the  user. 

2.3.4.2.3.3  Subroutine  CANCL  (NTRY).  This  subroutine  is  used  to  cancel  an  entry  in 
the  event  file  whose  first  cell  is  NTRY.  Cancellation  of  an  event  consists  of  removing  it  from 
the  file  storage  array,  updating  'ITNEX  if  the  event  was  tlie  next  event,  loading  tlie  buffer 
ATRIB,  and  updating  file  statistics.  In  other  words,  cancellation  consists  of  the  same 
functions  as  removal. 

Subroutine  CANCL  is  included  only  for  its  mnemonic  value  and  is  equivalent  to  the 
direct  use  of  the  statement  CALL  RMOVE  (NTRY,  + 1). 
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2.3.4.2.3.4  Subroutine  COPY  (NTRY).  This  subroutine  is  called  to  copy  the  values  of 
the  attributes  of  entry  NTRY  to  the  buffer  ATRIB.  Copying  an  entry  does  not  change  the 
file  storage  area  or  its  associated  statistics  in  any  way. 

2.3.4.2.4  Location  of  state  conditions  and  entities 

Two  functions,  KROSS  and  NFIND,  are  included  in  GASP  IV  for  location  purposes. 
Function  KROSS  assists  in  locating  the  time  at  which  sptvified  state  conditions  are  met. 
NFIND  is  used  to  identify  the  first  cell  of  an  entry  having  an  attribute  with  a specifitKl  value 
in  a particular  file. 


2.3.4. 2.4.1  Function  KROSS.  This  function  locates  specified  state  conditions  and 
returns  a codtnl  value  indicating  whether  the  conditions  have  been  met,  not  met,  or 
exctH*ded. 

Function  KROSS  is  used  primarily  in  subroutine  SCOND  and  performs  the  dual 
functions  of  causing  subroutine  G.\SP  (through  its  calls  to  SCONDl  to  ’‘s«>arch”  for 
■spivified  state  conditions  and  marking  the  satisfaction  of  those  conditions.  The  first 
function  is  accomplishetl  through  use  of  the  G.\SP  IV  control  variable  ISEKS.  The  swond  is 
accomplished  by  returning  a coded  value  of  KROSS,  indicating  that  a crossing  has  occumH.1. 

A crossing  may  be  either  positive  or  negative.  A positive  crossing  occurs  when  a variable 
(the  crossing  variable)  increases  in  value  from  "less  than"  to  "greater  than"  or  "equal  to”  a 
stH-ond  variable  (the  crossed  variable),  times  a multiplicative  constant,  plus  an  additive 
constant.  Both  the  crossing  and  crosstni  variables  must  be  state  variables  when  using  KRt)SS, 
and  they  are  identified  by  their  subscripts.  A zero  value  for  the  subsi'ript  of  the  crossed 
variable  or  a zero  value  of  the  multiplicative  constant  reduces  the  crossing  description  to  one 
of  a variable  crossing  a constant.  The  concept  of  a negative  crossing  is  analogous  to  that  of  a 
positive  crossing. 

A crossing  is  defined  as  Iwing  located  with  sufficient  precision  if  (1)  a discrete  change 
caused  the  crossing,  in  which  case  the  crossing  is  located  exactly  in  time  or  (2)  a time 
advance  caused  the  crossing  and  the  difference  at  the  end  of  the  3tep  IxHween  the  crossing 
variable  and  the  crossed  function  is  less  than,  or  equal  to,  the  prest-riln'd  tolerance. 

The  user  specifies  not  only  the  state  conditions  and  tolerances  defining  a crossing  but 
also  the  direction  of  crossing.  Thus  it  is  possible  to  search  for  and  identify  either  negative  or 
positive  crossings  or  both.  This  flexibility  permits,  for  example,  the  location  of  a local 
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maximum  (or  point  of  inflection)  hy  defining  a negative  crossing  of  zero  by  the  derivative  of 
the  variable  of  inter»*st. 


2.3.4.2.4.2  Function  NFIND.  Function  NFIND  is  list'd  to  locate  entries  in  NSET. 
NFIND  is  set  equal  to  the  first  cell  number  of  the  entry.  The  first  argument  specifies  a value 
for  attribute  comparison.  The  second  argument  of  NFIND  is  the  code  for  the  type  of  search. 
Argument  3 specifies  the  file  number,  and  argument  4 specifies  which  number  of  the 
attribute  is  compared.  The  fifth  argument  is  a tolerance  for  searches  seeking  e<{uality. 

2.3.4.2.5  Data  collection,  computation,  and  reporting 

GASP  IV  includes  eight  subroutines  that  support  data  collection,  computation,  and 
reporting.  Subroutines  COLCT,  TIMST,  HISTO,  and  GPLOT  each  perform  all  three 
functions.  The  user  normally  employs  only  the  collection  mode  since  the  computation  and 
reporting  mode  am  automatically  used  during  the  preparation  of  a GASP  IV  summary 
report.  Subroutine  TIMSA  is  used  only  for  data  collection.  Subroutines  PRNTQ  and  PRNTS 
perform  only  computation  and  reporting.  They  are  normally  used  during  the  preparation  of 
the  echo  check  and  again  during  the  preparation  of  tlie  summary  report.  Subroutine 
SlIMRY  performs  only  a reporting  function.  It  is  normally  called  by  subroutine  GASP  to 
provide  a complete  summary  report.  However,  SUMRY  can  be  called  by  the  user  at  any 
time  without  altering  any  GASP  IV  variables. 


2.3. 4.2.5. 1 Subroutine  COLCT.  This  subroutine  collects  sample  data  for  variables 
based  on  an  observation  of  the  variable  when  used  in  the  collection  mode.  In  the 
computation  and  reporting  mode,  it  calculates  the  mean,  standard  deviation,  standard 
deviation  of  the  mean  (assuming  independent  observations),  coefficient  of  variation, 
minimum,  maximum,  and  number  of  observations.  It  also  provides  tabular  output  of  the 
calculated  statistics. 

2.3.4.2.5.2  Subroutine  TIMST.  Subroutine  TIMST  is  also  used  for  collecting  values  of 
variables  for  which  statistical  estimates  are  desired.  When  TIMST  is  used,  the  variable  in 
question  is  as.sumed  to  have  maintained  a constant  value  over  a time  interval.  This  type  of 
variable  is  referred  to  as  a time  persistent  variable.  An  example  of  a time  persistent  variable 
would  be  the  number  of  customers  in  a queueing  system.  The  number  of  customers  in  a 
queueing  system  has  a constant  value  over  a time  interval  before  it  is  changed.  The  length  of 
the  time  inU*rval  dictates  the  weight  assigned  to  the  value  of  the  variable  in  computing  its 
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average  over  the  entire  simulation.  Subroutine  TIMST  integrates  the  value  of  the  variable 
over  the  time  interval  by  multiplying  these  two  quantities  together. 

2.3.4.2.5.3  Subroutine  TIMSA.  Subroutine  TIMSA  performs  tlie  same  function  as 
.subroutine  TIMST  except  that  the  averiige  of  the  last  value  observed  and  the  current  value 
are  used  to  integrate  the  time  persistent  variable.  TIMSA  is  particularly  useful  for  keeping 
statistics  on  state  variables,  since  their  values  are  permitted  to  change  between  events  as  well 
as  at  event  times.  The  trapizoidal  integration  used  in  TIMSA  yields  lietter  estimates  for  such 
variables  than  does  TIMST.  By  data  input,  the  number  of  variables  for  which  TIMST  and 
riMSA  are  used  is  defined  as  the  variable  NNSTA.  Clearly,  since  SSTl’V  is  used  by  TIMST 
and  TIMS.A,  different  numeric  codes  must  be  assignetl  to  variables  using  these  two 
subroutines.  Initial  values  of  time  persistent  variables  for  statistical  calculations  must  be  set 
either  by  standanl  G.ASP  IV  input,  by  an  initial  call  to  TIMST  or  Tl.MSA,  or  by  setting 
SSTPV(1,6)  in  the  main  program. 

2.3.4.2.5.4  Subroutine  HISTO.  Subroutine  HISIX)  is  ase<l  to  determine  the  relative 
frequency  with  which  a variable  falls  within  a set  of  prescrilied  limits.  It  is  normally  used  for 
variables  that  have  a prescribed  value  based  on  an  observation,  such  as  tlie  time  in  the 
system  for  a customer,  TISYS.  The  lower  limit  and  width  of  each  cell  of  the  histogram  are 
described  by  data  input  for  each  histogram.  The  array  JJCEL  is  used  to  store  the  histogram. 
The  number  of  cells  for  histogram  1 is  specified  by  input  and  stored  in  the  array  NNCKL(l). 
The  upper  limit  of  the  first  cell  and  Uie  width  of  each  cell  of  histogram  1 is  spwifi«l  by 
input  and  stored  in  the  lurays  HHLOW(l)  and  HHVVlD(l),  resfui  tively.  .As  with  .subroutim*s 
COLCT  and  TIMST,  subroutine  HISTO  is  used  to  print  and  to  plot  histograms  and  can  be 
called  by  the  user.  Histograms  are  automatically  printed  at  the  end  of  a simulation  nin  as 
part  of  the  GASP  IV  summary  rejiort. 

2.3.4.2.5.5  Subroutine  GPLOT.  Subroutine  GPLOT  collects  values  for  eventual 
plotting  of  up  to  10  dependent  variables  for  one  independent  variable.  The  independent 
variable  must  be  monotonic.  Many  options  are  available  with  regard  to  the  type  and  scaling 
for  the  plot.  At  most,  10  plots,  each  with  10  dependent  variables,  can  l>e  stored  on  tape 
units.  Significant  reduction  in  computing  time  is  obtained  when  the  plot  data  are  stored  in 
core  memory.  GASP  IV  provides  the  capability  for  maintaining  the  values  for  one  plot  in 
core. 

The  first  argument  of  GPLOT  is  a dimension  variable  that  accepts  up  to  10  values.  Since 
the  dummy  argument  in  the  subroutine  is  dimensioned,  there  are  various  ways  of  passing  the 
dependent  variables  to  the  plotting  subroutine. 
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2.3.4.2.5.6  Subroutines  PRNTQ  and  PRNTS.  Subroutines  PRNTQ  and  PRNTS  are 
used  to  print  the  filing  array  and  the  state  storage  vectors,  respectively.  The  statement 
CALL  PRNTQC"  ''ould  cause  the  computation  and  printing  of  the  average  number, 
standard  deviation,  and  maximum  number  of  entries  in  file  2,  and  would  prepare  a tabular 
listing  of  the  contents  of  file  2.  The  statement  CALL  PRNTQ(O)  would  perform  the 
procedure  for  all  files.  The  statement  CALL  PRNTS  would  cause  the  state  variables  and 
their  derivatives  to  be  printed  out. 

When  the  entire  file  storage  area  is  requested,  subroutine  PRNTQ  computes  and  prints 
the  maximum  number  of  entries  stored  in  the  file  storage  array  since  it  was  last  initialized. 
This  information  is  obtained  from  a sequential  search  of  predecessor  pointers.  The  first 
entry  having  a negative  predecessor  pointer  is  the  first  entry  that  has  not  been  used.  The 
normal  listing  for  each  file  includes:  (1)  the  current  simulated  time,  (2)  the  time  the  file 
was  last  used,  (3)  the  time-integrated  average  and  standard  deviation  of  the  number  of 
entries  in  the  file  (not  included  if  current  time  is  equal  to  file  initialization  time),  (4)  the 
maximum  number  of  entries  in  the  file  since  last  initialization  (not  included  if  current  time 
is  equal  to  initialization  time),  and  (5)  a sequential  listing  of  the  entries  currently  in  the  file. 

2.3.4.2.b.7  Subroutine  SUMRY.  SUMRY  provides  all  standard  GASP  IV  output  by 
either  printing  or  causing  all  of  the  following  to  be  printed: 

1.  A heading, 

2.  All  parameter  sets, 

3.  All  statistics  for  variables  based  on  observation, 

4.  All  statistics  for  time  persistent  variables, 

5.  All  files  and  file  statistics, 

6.  All  state  and  derivative  values, 

7.  All  histograms,  and 

8.  All  tables  and  plots. 

2.3.4.2.6  Program  monitoring  and  error  reporting 

The  functions  of  monitoring  and  error  reporting  are  supported  by  subroutines  MONTR 
and  ERROR.  These  subroutines  are  good  candidates  for  user  modification  to  obtain  specific 
information  for  use  during  the  debugging  of  a simulation  program. 

2.3.4.2.6.1  Subroutine  MONTR.  This  subroutine  selectively  provides  any  of  the 
following  functions  during  a simulation  run: 
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0.  start  or  stop  tracing  each  event. 

1.  Print  contents  of  files. 

2.  Reset  file  statistics  and  clear  statistical  storage  arrays. 

3.  Print  contents  of  state  storage  arrays. 

4.  Print  information  on  state  variables  and  files. 

5.  Print  summary  report. 

6.  Cause  error  exit. 

Subroutine  MONTR  may  be  called  directly  by  the  user  (after  assigning  an  appropriate 
value  to  the  event  code,  JEVNT),  or  by  the  occurrence  of  a monitor  event  (any  time-event 
with  an  event  code  less  than  zero). 

2.3.4.2.6.2  Subroutine  ERROR.  ERROR  is  called  when  an  error  is  detectetl  in  a GASP 
IV  subprogram.  The  error  message  provides  the  programmer  with  a code  (KODE)  that 
indicates  the  condition  causing  the  error  and  the  location  of  its  detection. 

Because  ERROR  may  be  called  by  subroutines  that  are  called  by  ERROR,  a loop 
protection  variable  (NERR)  is  used  to  assure  that  a loop  does  not  persist. 

Subroutine  ERROR  provides  useful  diagnostic  information  by  listing  the  error  code, 
simulated  time,  and  current  values  in  the  file  storage  buffer.  Next,  a call  to  tlie  user-provided 
subroutine  UERR  permits  any  specific  information  to  be  output.  A complete  summary 
report  is  then  prepared  (if  possible)  and  the  error  message  is  repeated.  Finally,  ERROR 
causes  a FORTRAN  error  to  take  advantage  of  FORTRAN-provided  diagnostic  and 
traceback  information. 

2.3.4.2.7  Miscellaneous  support 

The  miscellaneous  support  subroutines  included  with  GASP  IV  are  functions  SUMQ, 
PRODQ,  and  GTABL  and  subroutine  GDLAY. 

2.3.4.2.7.1  Functions  SUMQ  and  PRODQ  The  function  SUMQ  computes  the  sum  of 
all  attribute  values  for  a given  file.  Suppose  that  the  assets  of  a corporation  are  stored  in  file 
2 with  attribute  3 being  used  to  define  the  value  of  an  asset.  The  statement  TASSC  = SUMQ 
(3.2)  computes  the  value  of  the  total  assets  of  the  corporation  as  TASSC.  The  function 
PRODQ  performs  a similar  function  to  SUMQ  but  multiplies  the  values  of  the  attributes 
instead  of  summing  them.  Therefore,  if  the  components  logically,  in  series,  in  a system,  iu-e 
storwl  as  entries  in  file  3,  and  attribute  4 is  the  reliability  of  a component,  the  statement 
SREL  = PRODQ(  l.3)  will  compuU'  the  system  reliability  SREL. 
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2.3.4.2.7.2  Function  GTABL.  The  function  GTABL  provides  a look-up  function  for  a 
table  in  which  the  independent  variable  of  the  table  has  equal  intervals.  The  arguments  of 
GTABL  include:  (1)  the  name  of  the  array  storing  the  table  that  defines  the  function,  (2) 
the  value  of  the  independent  variable  for  which  the  function  is  to  be  evaluated,  (3)  the  value 
of  the  independent  variable  corresponding  to  the  first  and  last  tabulated  value,  (4)  and  the 
interval  of  the  independent  variable  corresponding  to  the  interval  between  the  tabulated 
values. 

2.3.4.2.7.3  Subroutine  GDLAY.  Subroutine  GDLAY  provides  a vehicle  to  obtain  a 
variable  order  exponential  delay  for  use  in  systems  dynamics  and  simulations.  Using  this 
subroutine,  state  variables  can  be  driven  from  their  current  value  to  a prescribed  value  in  a 
specified  number  of  stages.  At  each  stage  a specified  amount  of  delay  is  encountertxl.  To  use 
GDLAY,  each  stage  must  be  represtmted  by  a DD(*)  variable.  GASP  IV  automatically 
updates  corresponding  SS(‘)  variables  in  subroutine  GASP. 

2.3.4.2.8  Dummy  subroutines 

Dummy  subroutines  for  all  the  user  written  subroutines  are  included  in  the  GASP  IV 
package.  Their  inclusion  permits  the  user  to  code  only  those  subroutines  that  are  needed  for 
a given  simulation.  The  executable  statement  in  each  of  tlie  dummy  subroutines  is  to 
comply  with  the  requirement  of  ANSI  FORTRAN  that  every  subprogram  have  at  least  one 
executable  statement. 

2.3.4.2.9  Random  deviate  generators 

To  write  general  purpose  subprograms  for  generating  random  deviates  (samples),  one 
must  be  able  to  reference  parameter  values  for  the  distributions  to  be  sampled  within 
various  subprograms.  This  is  accomplished  in  GASP  IV  through  a two  dimensional  array, 
PPARM.  Each  row  of  PPARM  contains  a set  of  values  that  are  used  as  the  parameters  of  a 
distribution.  Since  the  parameters  are  stored  in  rows  of  PPARM,  it  is  only  necessary  to 
designate  the  row  number  when  calling  a subprogram  that  requires  parameter  values. 
PPARM  is  initialized  in  subroutine  DATIN  through  data  cards,  and  the  values  of  PPARM  are 
printed  to  ensure  that  the  values  used  in  a simulation  are  rt‘corded. 

GASP  IV  provides  the  mechanism  to  obtain  deviates  given  a distribution  type  and 
parameters  for  the  distribution.  The  data  collection,  sUitistical  ..  •'lysis  (including 
goodness-of-fit  testing),  and  modeling  to  describe  the  inputs  to  a simulation  must  1h> 
l^erformed  by  the  user. 
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GASP  IV  provides  subprograms  for  generating  deviates  from  Uie  following  distribution 
types  as  listed  in  Table  2. 3. 4. 2-2:  uniform  or  rectangular,  triangular,  normal,  log-normal. 
Erlang  (gamma  with  an  integer  parameter).  Gamma,  Beta,  and  Poisson.  The  uniform, 
triangular.  Erlang,  and  Poisson  types  employ  the  probability-integral-transformation 
approach  to  random  deviate  generation.  The  Beta  and  Gamma  generators  use  a derived 
analytic  result  in  conjunction  with  a rejection  technique.  A deviate  from  the  exponential 
distribution  can  be  obtained  from  the  Erlang  function  or  through  the  writing  of  a single 
statement. 

2.3.5  User-Written  Subroutines 

2.3.5. 1 Subroutine  Descriptions 

In  addition  to  the  main  program,  the  user  communicates  with  GASP  IV  through  the 
subroutines  described  in  Table  2. 3. 5.1-1. 

The  function  of  the  main  program,  EVNTS,  INTLC,  and  OTPUT  were  descrilx>d 
previously.  Subroutine  UERh  allows  the  user  the  option  of  performing  operations  and 
printing  specific  information  when  a GASP  IV  error  is  detected. 


TABLE  2.3.4.2-2.  RANDOM  DEVIATE  GENERATORS 


Random  Daviatt  Ganarator 

Typo  of  Oistributlon 

GRAND 

Uniform  distribution  on  intarval  0-1  (psaudorandom  number). 

UNFRM 

Uniform  distribution  on  a spacifiad  intarval  (ULO,  UHI). 

TRIAG  ' 

Triangular  distribution. 

RNORM 

Uniform  distribution  on  ths  spacifiad  portion  of  an  array. 

RLOG 

Lognormal  distribution. 

ERLNG 

Eriand  distriubtion  (gamma  distribution  with  an  a paramatar). 

NPSSN 

Poisaon  distribution. 

GAM 

Support  routins  used  to  obtain  a sampla  from  a Gamma  or 
or  Bota  distribution. 

GAMA 

BETA 


Gtmma  distribution. 
Bota  distribution. 


2.3.5.2  Input  Formats 


All  GASP  IV  variables  are  initialized  by  data  card  inputs.  Each  data  input  is  associaUnl 
with  a specific  data  card  in  a specified  format.  A total  of  fourteen  data  canl  types  are 
specified  for  complete  initialization. 


TABLE  2.3.S.M.  DESCRIPTION  OF  USER  WRITTEN  SUBROUTINES* 


Name 


Description 


Subroutine  EVNTS  (IX)  Called  by  subroutine  GASP  to  process  event  IX.  A computed  GO  TO  statement  with  argument 

IX  is  used  to  transfer  to  the  appropriate  time^vent  processing  subroutine;  however,  if 
IX  ■ IIEVT  must  be  made  by  the  user  in  EVNTS;  normally  the  vector  LFLAG  is  used 
for  this  purpose  where  LFLAGd)  is  set  by  the  user  in  subroutine  SCOND;  the  form  of 
subroutine  EVNTS  is  illustrated  in  Figure  3-3. 

Subroutine  OTPUT  OTPUT  provides  a way  for  the  user  to  obtain  output  in  addition  to  the  standard  GASP  IV 

summary  report;  OTPUT  is  called  prior  to  subroutine  SUMRY  and  can  be  used  as  an 
end-of-simulation  event. 

Subroutine  UERR  (KOOE)  Called  by  subroutine  ERROR  to  allow  the  user  to  print  specific  information  if  an  error  occurs. 

Subroutine  INTLC  Can  be  used  to  initialize  state  variables  and  non-GASP  variables;  called  in  subroutine  OATIN 

after  all  GASP  IV  data  cards  have  been  read. 

Subroutine  STATE  Defines  state  variables  through  a listing  of  difference  or  derivative  equations  or  both;  called  by 

subroutine  DATIN  (after  INTLC  is  called)  and  then  by  subroutine  GASP  to  compute 
current  values  of  state  variables;  TNOW  is  the  time  to  which  GASP  IV  is  trying  to 
advance  when  STATE  is  called;  DTNOW  is  the  increment  involved  in  the  current  up- 
date. 

Subroutine  SCONO  Called  by  subroutine  GASP  to  determine  if  a state-event  has  occurred.  State-events  are  nor- 
mally defined  in  terms  of  state  variables  crossing  a prescribed  threshold  or  a prescribed 
variable  with  a tolerance  specified  for  the  amount  of  overcrossing.  In  SCONO,  the  user 
must  make  certain  the  value  of  the  GASP  IV  variable  ISEES  is  set  to  communicate  if  a 
state-event  has  been  passed  (ISEES  < 0),  if  no  state-event  hat  been  passed  (ISEES  ^ 0), 
or  if  no  state-event  has  been  passed  but  one  does  end  the  current  step  (ISEES  > 0). 

When  function  KROSS  is  used,  ISEES  is  automatically  set;  the  user  should  indicate  through 
the  setting  of  a variable  whan  a state-event  occurs;  the  GASP  IV  vector  LFLAG  can  be 
used  for  this  purpose  and  the  user  can  test  LFLAG  in  the  user  written  stateevent  rou- 
tines; the  LFLAG  vector  is  not  tested  in  GASP  IV;  after  a return  from  EVNTS,  subrou- 
tin  GASP  sets  LFLAGd)  > 0 for  I « I,  NFLAG. 

Subroutine  SSAVE  Called  by  subroutinTGASP'ivscaially  to  record  system  status;  the  value  of  OTSAV  specified 

the  frequency  with  which  SSAVEYreelled  as  follows:  i 

OTSAV  < 0 SSAVE  called  only  at  event  times  ^ 

OTSAV  ° 0 SSAVE  called  at  each  accepted  update  point,  that  is, 

at  the  end  of  eKh  time  step  (which  includes  all  event  timet) 
OTSAV  > 0 SSAVE  called  each  OTSAV  time  units  and  at  event  times 
Through  SSAVE  the  utar  collects  the  data  desired  for  eventual  printout. 


The  utar  normally  also  writes  a subroutine  for  each  type  of  event  included  in  a model. 


2.3.6  SIMNUC 
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2.3.6. 1 Purpose  of  Computer  Program 

The  Basic  Simulator  (SIMNUC)  is  an  integrated  package  of  subprograms  designed  to 
facilitate  modeling  and  simulation  of  discrete  stochastic  systems  in  a manner  similar  to  the 
GASP  IV  simulation  programs. 

The  following  features  characterize  this  package; 

1.  Model  independence. 

2.  FORTRAN  orientation  - the  user’s  portion  of  a simulator  can  be  programmed  in 
FORTRAN  or,  if  desired,  in  assembly  language. 

3.  Capability  to  produce  event-oriented  simulation  models. 

•1.  Availability  of  list  processing  and  dynamic  memory  management  facilities. 

5.  Capability  to  collect  and  display  standard  queue  and  sample  statistics. 

6.  A full  complement  of  random  number  generators. 

The  basic  approach,  which  sometimes  is  referred  to  as  n simulation-world-view,  used  to 
model  discrete  systems  for  digital  simulation  with  the  Basic  Simulator  is  the  event-oriented 
approach,  which  emphasizes  decomposition  of  the  simulation  process  into  individual  event 
procedures,  each  of  which  describes  all  changes  in  the  system  caused  by  the  occurrence  of 
the  related  event,  just  as  was  done  in  GASP  IV. 

2.3.6.2  Simulation  Facilities 

The  Basic  Simulator  consists  of  the  following  functional  software  components: 

1.  Simulation  Run  Control, 

2.  Dynamic  Memory  Management, 

3.  List  Processing, 

4.  Random  Number  Generators. 

5.  Sample  Statistics  Processing,  and 

6.  Error  Diagnosis  and  Reporting. 

2.3.6.3  Program  Organization  and  Simulation  Run  Control 

The  components  of  the  Basic  Simulator  are  designed  as  independent  FORTRAN  callable 
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subptx>jn^ims  sii  that  Uu'  usor  iuhm.!  only  include  tliose  subproj,Tams  necessan.’  for  his 
particular  simulation.  The  Basic  Simulator  subproj^-ams  may.  in  turn,  require  other 
subpn)priuns  such  as  diagnostic  routines.  The  only  case  with  which  the  user  must  be 
concermxl  is  the  Dynamic  Memory  (’omponent,  which  is  initialized  if  the  List  Processing  or 

Simulation  Control  Components  are  used.  By  including  the  block  data  subprogram,  ^ 

SSDATX,  all  components  except  Dynamic  Memory  an*  initialized.  Dynamic  Memory  is 
initializwl  by  a call  to  the  subprogram  MINITX. 

As  indicattnl  in  Figure  2. 3.6-1,  the  Main  Program  consists  of  two  lineju-ly  stnictured 
program  segments,  which  will  be  called  the  Initialuation  and  Termination  Tarts  of  the  Main 
Program. 

The  main  function  of  the  Initialization  Part  is  to  complete  the  following  task: 

1.  Initialize  a relatively  small  set  of  model-independent.  Basic  Simulator  control 

I parameters,  such  as  tliost>  ust'd  by  the  Simulation  Control  and  Dynamic  Memory 

' Components  (this  task  is  further  discussed  in  “Special  Programming 

^ Requirements”). 

2.  Read  input  data  and  possibly  print  its  summary’;  the  input  data  typically  can  Ih‘ 
divided  into  two  categories:  (a)  the  user-supplied  simulation  control  parmneters, 
and  (b)  model  definition  data. 

After  reading  all  input  data,  the  internal  representation  of  mixlel  definition  can  be 
completetl— this  action  may  require  processing  of  tire  model  definition  data  and 
construction  of  viurious  data  structures  (such  as  tables,  lists,  etc.)  from  the  (irocesst'd  data. 

3.  Initialize  the  problem-dependent  control  parameters  and  data  structures  in  ortler  to 
bring  the  system  to  be  simutatwl  to  its  initial  state;  Uiis  task  may  include  (a) 

• creation,  or  definition,  of  sample  statistic-gathering  mechanisms,  (b)  definition  of 

model  dependent  queues,  (c)  initialization  of  random  number  sequences. 

4.  Define  all  event  coordination  structures. 

5.  Schtxlule  initial  events. 

The  Dynamic  Memory  is  initialized  by  calling  the  .subprogram  MINITX.  Since  MINITX 
builds  the  Free  List,  it  must  be  called  before  any  other  routine  that  assesses  Dynamic 
Memory  subroutint's,  either  directly  or  indirectly,  is  calUxI. 

The  us«*r  must  properly  define  a labeletl  COMMON  block.  MF.MXXX.  containing  the 
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MKMOKY  vtx-tor  for  Dynamii-  M»*nu)r>’  stonvge  sjwut!;  the  user  must  also  sjuvify  all  reiiuiroil 
tHiuivalenees  aiul  types  fi»r  tlu>  variables  ustxl  in  setting;  up  the  Dyuanue  Memory  fnunework. 

In  the  mitialization  part  of  the  mam  program,  a separate  event  eoonlmation  stnieture 
must  he  defmeil  by  eallin^  DKFt'SX  for  eaeh  elass  of  bloekable  events  in  the  simulation 
mixlel. 

After  all  initialization  is  eomplete.  the  simulation  proeess  is  started  by  eallin^  the  sub- 
projtnim  t'lDSlMX,  This  FOK  THAN  subroutine  exeeutes  the  simulation  run  eontrol  fune 
tions  whieh  can  Iv  staU*d  as  follows: 

1.  lYansfer  the  run  control  from  the  initialization  Part  of  the  Main  Pro^^'am  to  the 
Simulation  Process  (i.e.,  events  jiosUhI  on  the  Future  tXent  last). 

2.  Kstablish  the  first  exivuUible  statement  which  follows  the  call  to  tlOSlMX  as  the 
rivnUry  tnunt  to  the  Main  Program. 

3.  Post  the  event  notice  for  the  final  event  (for  terminating  the  simulation  process)  to 
occur  at  a time  point  which  is  to  be  expresstH.1  in  terms  of  the  simulation  time  units. 

The  subprogram  KDSMRX  is  responsible  for  determining  the  simulation  termination 
conditions.  Two  types  of  simulation  termination  conditions  will  Ih'  recognized; 

1.  Normal  termination  of  a simulation  process,  which  technically  means  the  occurivnce 
of  the  final  event  that  has  been  prt'sent  by  the  user;  and 

2.  Detivtion  of  an  error  condition. 

After  the  run  control  has  been  transfernxl  to  the  simulation  proe'ess  (i.e.,  to  tJie  events 
posttxl  on  the  h\itutv  tXent  List),  it  is  rtdunuHl  to  the  Main  Pri>grum  only  after  a 
termination  condition  of  tyjre  one  arises.  Type  2 above  rt'fers  only  to  those  error  conditions 
that  can  be  detectwl  by  means  of  the  Krwr  Diagnosis  and  Reporting  Subroutines:  many 
other  types  of  errors  may  arise  during  a simulation  run.  and  they  may  remain  undeteettHt  by 
these  subroutim*s. 

.As  indicatixl  in  Figim'  2. 3.6- 1,  CiOSlMX  is  invoked  from  the  Initialization  Part  of  the 
Main  Program  (which  means  that  it  is  a user-accessible  subprogram),  and  KDSMRX  is 
automatically  calUxl  (i.e.,  without  an  explicit  intervention  by  the  user's  part  of  the 
simulator)  after  one  of  the  alx^ve-statiHl  termination  conditions  arises. 
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If  the  termination  is  of  type  2,  the  user-supplieti  error  reporting  routine  is  executed,  if 
present,  to  provide  the  user  with  any  partial  results  that  he  may  require.  The  simulation 
program  is  then  terminateti  witliout  return  to  the  Termination  Part  of  the  Main  Program. 

If  the  termination  is  normal  (type  11,  control  is  returnwl  to  the  I'ermination  Part  of  the 
Main  Program  which  follows  the  call  to  GOSIMX.  The  statement  imimxliately  following  Uie 
call  to  t'lOSlMX  can  he  consider'd  to  Ih'  the  starting  ^K)int  of  the  Termination  Part  of  the 
Main  Program. 

.\s  in  the  case  of  the  Initialization  Part,  the  functions  of  the  Termination  Part  ar»'  model 
dependent  and  typically  consist  of  the  following  tasks; 

1.  Compute  the  end-of-run  simulation  statistics. 

2.  Write  end-of-run  reports. 

The  computation  of  eiul-of-nin  statistics  includes  those  operations  on  ample  ;md  queue 
statistics  which  can  he  performtnl  only  after  the  termination  of  the  simulation  process,  such 
as  obtaining  final  values  for  .sample  means  and  standan.1  ileviations.  Certain  standard  types  of 
s;imple  and  list  (queue)  statistics  can  he  gathered  during  simulation  hy  means  of  the  facilities 


of  the  Siunple  Statistics  Pncessing  imd  the  List  Processing  Components,  respt'ctively. 

The  Sample  Statistics  Processing  Components  also  contain  suhroutines  for  performing 
the  end-of-simulation  computations  on  gathert'd  statistics  and  for  displaying  computtxl 
results. 

2. 3. 6. 4 Component  Functional  Description 

The  subprograms  of  the  Basic  Simulator  an'  divided  into  six  major  groups,  calk'd 
components,  which  perform  the  following  functions:  simulation  control,  memory 
management,  list  processing,  random  number  genenition.  v>rocessing  of  sample  .statistics,  and 
error  diagnostics. 

2.3. 6. 4.1  Control  of  the  simulation  process 

This  section  ilescrihes  the  facilities  in  the  Basic  Simulator  whose  function  is  to  provule 
the  user  with  tools  for  initializing  and  controlling  a simulation  process,  (.’ollectively.  these 
control  facilities  will  he  referred  to  as  the  Simulation  t'i>ntr<.>l  t'omtionent  (SCO  of  the 
Basic  Simulator. 
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Tho  Simulation  Control  Componont  consists  of  programs  to  manage  the  orderly 
initiation  of  the  simulation  process,  the  transition  from  one  event  to  another,  and  the 
termination  of  the  simulation  process.  The  Simulation  Control  Component  of  the  Basic 
Simulator  makes  it  po.s.sible  to  simulate  concurrent  processes  by  representing  each  process  as 
a sequence  of  events.  In  a simulation  program,  events  are  repre.sented  by  the  so-called  event 
routines.  The  occurrence  of  an  event  during  simulation  is  represented  by  a data  structure, 
called  an  event  notice,  which  contains  the  following  information  about  the  event: 

1 . The  future  time-of-occurrence  of  that  event, 

2.  The  entry  point  address  of  the  corresponding  event  routine,  and 

3.  Additional  information,  if  any,  to  be  passtxl  to  the  event  routine. 

The  last  item  provides  the  capability  to  pass  input  parameters  to  event  routines. 

2.3.6.4.1.1  Functional  Description.  Since  control  of  the  Basic  Simulator  is  exerci.sed  l)y 
following  the  next-event  principle,  as  in  GASP  IV,  the  user’s  portion  of  the  simulator 
software  consists  of  a master  (main)  program  and  of  the  so-called  event  routines,  each  of 
which  represents  an  event  type  in  the  dynamic  model  of  the  .system  under  consideration. 

An  event  routine  must  be  coded  as  a FORTRAN  subprogram  without  arguments. 
Parameters  are  pa.s.sed  to  it  by  means  of  the  event  notice,  or  by  common  blocks.  Each  event 
routine  is  responsible  for  the  disposition  of  the  event  notice  which  invoked  it.  It  may  either 
re.schtxlule  the  event  notice  with  the  subprogram  SCHDFIX  or  free  the  dynamic  memory 
block  containing  the  event  notice.  The  event  routine  is  also  responsible  for  scheduling  any 
successor  events.  A RETURN  staUmient  must  always  be  used  to  exit  from  an  event  routine. 
This  causes  the  transfer  of  cotitrol  to  the  event  routine  which  is  to  be  executed  next.  The 
user’s  portion  of  the  simulator  may  contain  additional  subroutines  which  are  invoked  from 
the  main  program  or  from  the  event  routines. 

A simulation  run  starts  by  transferring  the  control  to  the  initial  .segment  of  the  main 
program  who.se  function  is  to  perform  various  tasks  associated  with  the  initialization  of 
simulation.  Defining  the  lists  to  be  used  in  simulation,  setting  up  mechanisms  for  statistics 
collection,  or  reading  and  preprocessing  of  model  data  are  examples  of  initialization  tasks. 
Once  this  has  been  done  the  run  control  must  be  passed  to  the  Simulation  Clock  Manager. 
The  latter  is  a mechanism,  consisting  of  .several  .subroutines  of  the  Basic  Simulator  that  are 
not  explicitly  .acce.ssible  to  the  user,  whose  main  function  is  to  manage  the  Future  Event 
List,  a major  data  structure  used  by  the  Simulation  Clock  Manager.  The  functions 
performed  by  the  Simulation  Clock  Manager  subprograms  are  to: 
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1.  Retru'vi'  tho  iiDliio  of  tl\o  most  immiiiiMit  fiituro  woiil  whirh  now  l>»>coim>s  thi- 
curn’nt  t'ci'rit)- 

2.  Advaiu-o  the  simulation  elock  to  the  lime  value  iiulieated  on  the  retrieved  event 
not  lee; 

3.  I'ransfer  the  run  eontrol  to  the  rrc/it  rouliiif  which  handles  all  events  of  the  type  to 
which  the  current  event  helonns; 

I,  tlenerate  and  post  future  event  notices  during  the  execution  of  the  event  routine; 
and 

5,  After  the  execution  of  the  event  routine  is  completed,  return  the  run  control  to  the 
Simulation  Clock  Manager,  which  then  recycles  the  steps  (a)  through  (e). 

The  simple  simulation  control  st’heme  descriluxl  above  is  not  sufficient  for  logically 
more  complex  modeling  situations  which,  for  example,  may  retiuire: 

1.  Suspension  of  the  execution  of  an  event  routine,  if  a test  performed  after  entering  it 
indicates  that  the  logical  conditions  for  its  further  execution  do  not  yet  exist;  or 

2.  Cancellatitm  of  an  event  notice  already  posted  on  the  Future  Kvent  List. 

The  Simulation  Control  Component  contains  facilities  for  handling  these  two  ahove 
descrilnnl  situations.  The  first  one  is  handled  by  means  of  the  so-calUxl  event  coordination 
structures  which  are  lists  used  to  store  the  notices  of  suspended  events.  Subprograms  are 
providiHl  for  defining  such  a structure,  for  suspending  an  event  by  placing  its  notice  on  the 
appropriate  event  coordination  structure,  and  for  releasing  all  event  notices  curn'ntly  on  a 
specified  event  coordination  structure.  Similarly,  a subprogram  is  provided  for  cancelling  the 
notice  on  the  Futim'  Kvent  List  of  a future  failure  event. 

2.3.6.4.1.2  SSC  SUBROUTINES.  The  Simulation  Control  Component  of  the  Basic 
Simulator  contains  the  following  subroutines: 


1. 

C.OSIMX  - 

Start  the  Simulation  I’rocess, 

2. 

ENTRYX  - 

Get  the  Entry  Address  to  a Subprogram, 

3. 

SCHDKX  - 

Schedule  an  Event, 

4. 

CALLEX  - 

Get  th*^  Entry  Addn'ss  of  the  Calling  Program, 

5. 

DEFCSX  - 

Define  an  Event  Coordination  Stnictim', 

B. 

BLCKEX  - 

Block  an  Event  Notice, 

7. 

RLSEEX  - 

Release  an  Event  Notice, 

8. 

FINDEX  - 

Get  the  Pointer  to  an  Event  Notice, 

CANCI.X  - 

Cancel  an  Event  Notice,  and 

10. 

TIMEXX  - 

Read  the  Clock. 
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InitializaMon  of  the  simulation  process,  which  U'chnically  means  transfer  of  control 
from  the  us«*r’s  main  proffram  to  the  Simulation  Clock  Manafjer,  is  the  function  of  GOSIMX, 
the  first  of  the  above  ten  subroutines.  Hence,  GOSIMX  must  1h*  called  from  the  user’s  main 
projiram  after  the  completion  of  tasks  associated  with  the  initialization  of  simulation.  Once 
the  simulation  control  is  pa.ssed  to  Uie  Simulation  Clock  Manager,  appropriate  user-suppliiKl 
(Went  routines  are  called  by  the  Simulation  Clock  Manager  according  to  the  event  notices 
posteil  on  the  Future  Kvent  List  until  the  end-of-simulation  time  is  reached.  At  that  instant, 
the  Simulation  Clock  Manager  returns  the  execution  control  to  the  user’s  main  program, 
with  the  reentry  point  being  the  first  stiitement  following  the  call  to  GOSIMX. 

I’he  remaining  subroutines,  following  GOSIMX  in  the  above  list,  are  normally  called 
from  the  user-written  event  routines  to  perform  various  simulation  control  functions  such  as 
posting  a future  event  notice,  blocking  and  then  releasing  an  event,  cancelling  a posted  event 
notice,  getting  the  current  simulation  time,  or  getting  a pointer  to  an  event  routine. 

2.3.6.4.1.3  GOSIMX  — Start  the  Simulation  Process.  This  subroutine  (riggers  the 
simulation  process  by  executing  the  transfer  of  control  from  the  user’s  main  program  to  the 
Simulation  Clock  .Manager;  it  al.so  .set.s  up  a ntechani.sni  for  returning  Die  control  to  the  main 
program  at  the  end  of  the  simulation  process.  Control  is  returned  to  that  statement  in  the 
main  program  which  follows  the  call  to  GOSIMX.  More  specifically,  GOSIMX  performs  the 
following  tasks; 

1.  Transfer  the  program-run  control  from  the  initialization  piu't  of  the  main  program  to 
the  Simidation  Clock  Mimager  (the  latter  may  be  thought  of  as  being  a simulation 
control  mechanism  which  is  not  explicitly  accessible  to  the  user). 

2.  K.stablish  the  first  executable  statement  which  follows  the  call  to  GOSIMX  as  the 
reentry  point  to  the  main  program. 

3.  Post  the  Kvent  Notice  for  the  final  simulation  event  which  will  return  control  to  the 
main  prt)gram. 

■1.  Specify  the  entry  point  of  a user-supplied  subprogram  which  is  to  be  executed  in  Die 
event  of  an  error  exit  termination  of  the  simulation  process. 

The  call  statement  for  GOSIMX  contains  two  arguments.  'I'he  first  argument  is  used  to 
.specify  the  time  of  termination  of  the  simulation.  If  a user-suppli»Hl  subroutine  is  to  be 
executed  before  the  termination  of  the  simulation  (irocess  due  to  a detected  error,  the 
second  argument  must  contain  a pointer  to  that  subroutine;  otherwise,  it  must  have  zero 
value. 
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2.3.6.4.1.4  ENTRYX  — Get  the  Entry  Address  to  a Subprogram.  Subprogram 
ENTRYX  computes  an  entry  point  address  of  (pointer  to)  a FORTRAN  subprogram. 

2.3.6.4.1.5  SCHDEX  — Schedule  an  Event.  This  subprogram  places  an  event  notice  on 
the  Future  Event  List.  The  arguments  of  SCHDEX  contain  user-supplied  information, 
specify  the  time  when  the  event  should  occur,  and  normally  contain  the  entry  point  address 
of  the  event  routine. 

2.3.6.4.1.6  CALLEX  - Get  the  Entry  Address  of  the  Calling  Program.  When  invoked 
in  a subprogram,  CALLEX  computes  the  entry  point  address  of  the  program  which  called 
the  subprogram. 

2.3.6.4.1.7  OEFCSX  — Define  an  Event  Coordination  Structure.  This  subprogram  is 
used  to  define  an  event  coordination  structure  (ECS).  A separate  event  coordination 
structure  must  be  defined  in  the  initialization  phase  of  a simulation  run  for  each  logically 
distinct  class  of  blockable  event  notices  in  the  simulation  model.  The  arguments  of  DEFCSX 
include  the  name  to  be  assigned  to  the  ECS,  and  the  pointer  to  be  used  for  all  future 
references  to  this  ECS. 

2.3.6.4.1.8  BLCKEX  — Block  an  Event  Notice.  This  subprogram  is  used  by  an  event 
routine  to  block  its  own  current  execution  by  putting  the  event  notice  for  itself  on  an 
appropriate  event  coordination  structure.  A blocked  event  remains  on  an  event  coordination 
structure  until  subroutine  RLSEEX,  described  in  the  sequel,  is  called  to  release  it.  BLCKEX 
returns  the  execution  control  to  the  calling  event  routine  which  is  blocking  itself;  hence, 
further  execution  of  this  routine  must  subsequently  be  halted  by  a RETURN  statement. 
The  arguments  of  BLCKEX  include  a pointer  to  the  event  coordination  structure  on  which 
the  notice  is  to  be  placed  and  a timing  parameter  used  by  RLSEEX  in  order  to  determine 
the  time  at  which  the  released  event  is  to  be  rescheduled. 

2.3.6.4.1.9  RLSEX  — Release  an  Event  Notice.  This  subprogram  is  used  to  release  all 
event  notices  that  have  been  blocked  on  a specified  event  coordination  structure. 
Technically,  the  release  of  blocked  event  notices  means  computing  new  future  occurrence 
times  for  the  blocked  events,  putting  these  time  values  in  the  event  notices,  and  then  moving 
these  notices  to  the  Future  Event  List. 

2.3.6.4.1.10  FINDEX  — Get  the  Pointer  to  an  Event  Notice.  This  subprogram  searches 
for  a specified  event  notice  on  the  Future  Event  List  (FEL).  If  FINDEX  succeeds  in  locating 
this  notice,  it  computes  and  returns  a pointer  to  the  notice;  otherwise,  this  pointer  is  given 
zero  value. 


2.3.6.4.1.11  CANCLX  — Cancel  an  Event  Notice.  This  subprogram  is  used  to  cancel  a 
specified  event  notice  on  the  Future  Event  List.  The  event  notice  is  specified  by  giving  its 
pointer,  which  may  be  computed  by  using  FINDEX  or  obtained  by  some  other  means. 


I 2.3.6.4.1.12  TIMEXX  — Read  the  Clock.  This  program  computes  the  current  value  of 

the  simulation  clock  (time),  which  is  a standard-length  integer. 

2.3.6. 4.2  Memory  management 

The  Dynamic  Memory  Management  Component  of  the  Basic  Simulator  provides  the  user 
with  the  capability  to  manage  dynamically  during  the  program  execution  a vector  of 
COMMON  memory  so  that  blocks  from  the  vector  can  be  temporarily  allocated  to  the  user’s 
program  and  then  deallocated  (freed)  when  no  longer  needed.  This  memory  management 
method  makes  it  possible  to  reuse  the  same  storage  many  times  for  different  purposes 
throughout  a simulation  run,  and  thus  not  only  to  minimize  total  program  storage 
requirements,  but  also  to  increase  the  size  of  the  simulation  problem  that  can  be  handled. 
With  this  method  of  memory  management,  the  following  allocation  is  used: 

1.  A block  in  dynamic  memory  must  always  be  allocated  (deallocated)  by  appropriate 
action  in  the  program,  and 

\ 2.  An  allocated  block  can  be  accessed  only  through  a pointer  which  is  set  up  at 

allocation  time. 

2.3.6.4.2.1  Functional  Description.  The  Dynamic  Memory  Management  Component 
allocates  storage  from  a vector  called  MEMORY  which  is  contained  in  the  labeled  COMMON 
block  MEMXXX.  The  user’s  program  accesses  a block  allocated  from  Dynamic  Memory 
through  a pointer  associated  with  that  block.  At  any  instant  of  program  execution,  the 
vector  MEMORY  consists  of  two  types  of  blocks:  those  that  are  allocated  and  currently  in 
use,  and  those  that  are  available  for  use.  All  deallocated  blocks  are  chained  together  into  a 
list  called  the  Free  List.  It  is  the  user’s  responsibility  to  put  memory  deallocation  requests  in 
appropriate  places  in  his  program. 

When  the  program  requests  a block  of  certain  size,  the  Free  List  is  searched  to  find  a 
deallocated  block  of  sufficient  size.  The  search/allocation  strategy  works  as  follows:  during 
the  search,  physically  adjacent  blocks  in  the  Free  List  are  coalesced  into  a single  large  block; 
the  requested  block  is  allocated  from  the  first  sufficiently  large  free  block  encountered  in 
this  search.  If  no  such  block  can  be  found,  further  execution  of  the  simulation  program  is 
terminated. 
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2.3.6.4.2.2  DMMC  SUBROUTINES.  The  Dynamic  Memory  Management  Component 
consists  of  the  following  subroutines: 


1.  MINITX- 

2.  MEMALX- 

3.  MEMFRX- 

4.  MEMZOX- 

5.  MEMDPX- 

6.  MCOPYX- 

7.  MSTATX- 


Initialize  Memory, 

Allocate  Memory, 

Free  (Deallocate)  Memory, 
Store  Zeroes  in  Memory, 
Dump  Memory, 

Copy  Memory,  and 
Write  Memory  Statistics. 


To  use  these  subroutines,  the  user  must  properly  define  a labeled  COMMON  block, 
MEMXXX,  containing  the  MEMORY  vector  for  Dynamic  Memory  storage  space;  the  user 
must  also  specify  all  required  equivalences  and  types  for  the  variables  used  in  setting  up  the 
Dynamic  Memory  framework. 


2.3.6.4.2.3  MINITX  — Initialize  Memory.  MINITX  is  used  to  initialize  the  memory 
vector  as  the  Free  List  from  which  blocks  of  memory  are  to  be  allocated.  The  arguments  of 
MINITX  are  the  length  in  words  of  the  memory  vector  specified  by  the  user  and  the  length 
in  words  of  the  desired  block  modulus. 


2.3.6.4.2.4  MEMALX  — Allocate  Memory.  This  subroutine  is  used  to  allocate  a block 
of  memory  from  the  Free  List.  The  user’s  portion  of  an  allocated  block  is  automatically 
zeroed.  If  such  a block  cannot  be  allocated  due  to  the  lack  of  storage,  simulation  is 
terminated. 


2.3.6.4.2.5  MEMFRX  - Free  (Deallocate)  Memory.  MEMFRX  is  used  to  free  an 
allocated  block  of  dynamic  memory  in  order  to  return  it  to  the  Free  List. 

2.3.6.4.2.6  MEMZOX  — Store  Zeroes  in  Memory.  The  subroutine  MEMZOX  can  be 
used  to  store  zeroes  in  all  user-available  words  of  a specified  Dynamic  Memory  block. 

2.3.6.4.2.7  MEMDPX  — Dump  Memory.  The  subroutine  MEMDPX  can  be  used  to 
dump  the  contents  of  Dynamic  Memory  for  program  debugging  purposes. 

2.3.6.4.2.8  MCOPYX  — Copy  Memory.  This  subroutine  can  be  used  to  create  a copy  of 
the  contents  of  a block  of  Dynamic  Memory  and  return  a pointer  to  the  block  of  Dynamic 
Memory  containing  the  copy.  The  contents  of  the  original  block  are  unmodified. 
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2.3.6.4.2.9  MSTATX  — Write  Memory  Statistics.  The  subroutine  MSTATX  writes  the 
Dynamic  Memory  statistics  for  the  line  printer.  These  statistics  are: 

1.  The  size  of  the  memory  vector, 

2.  The  maximum  number  of  words  which  were  allocated  at  any  time  until  the  call  to 

MSTATX,  and 

3.  The  number  of  words  currently  allocated. 

2.3.6.4.3  List  processing 

This  section  discusses  list  processing  facilities  available  to  the  user.  The  List  Processing 
Component  (LPC)  of  the  Basic  Simulator  provides  tools  for  handling  two  types  of  list 
structures,  doubly  linked  lists  (queues)  and  indexed  lists.  In  addition,  the  LPC  contains 
subroutines  for  collecting  standard  list  statistics. 

2.3.6.4.3.1  Functional  Description.  All  lists  maintained  by  the  List  Processing 
Component  use  the  facilities  of  Dynamic  Memory  both  for  storing  list  heads  and  list 
elements.  For  both  types  of  lists,  the  list  head  is  created  and  maintained  exclusively  by  LPC 
subroutines.  In  both  cases,  the  list  to  be  processed  is  identified  to  a List  Processing 
Component  subroutine  by  means  of  a pointer  to  the  head  of  that  particular  list  (such 
pointers  will  be  called  list-head  pointers). 

To  initialize  (create,  define)  a list,  the  user’s  program  must  set  aside  a variable  which  is 
to  function  as  the  list-head  pointer  for  that  list;  then  appropriate  action  must  be  taken  to 
create  the  list-head,  which  differs  for  each  type  of  list. 

2.3.6.4.3.2  LPC  Subroutines.  The  list  processing  subroutines  available  to  the  user  are 
listed  below.  For  convenience,  these  subroutines  are  divided  into  two  groups,  those  for 
processing  doubly  linked  lists  and  those  for  handling  indexed  lists: 

1.  Subroutines  for  Processing  Doubly  Linked  Lists: 

a.  LTDEFX  — Define  a List, 

b.  LTADDX  — Add  an  Element  to  a List, 

c.  LTDMPX  — Dump  a Linked  List, 

d.  LTFNDX  — Find  a Specified  Element  in  a List, 

e.  LTNXTX  — Find  Next  (First)  Element  in  a List,  and 

f.  LTRSPX  — Remove  a Specified  Element  From  a List. 
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2.  Subroutines  for  Processing  Indexed  Lists: 

a.  DSADDX  — Add  a New  Member  to  an  indexed  List, 

b.  DSDMPX  — Dump  an  Indexed  List, 

c.  DSNXTX  — Return  a Pointer  to  a Specific  Member  of  an  Indexed  List,  and 

d.  DSPRGX  — Purge  an  Indexed  List. 

2.3.6.4.3.3  Processing  of  Doubly  Linked  Lists  by  Means  of  LPC  Subroutines.  Every 
element  of  a doubly  linked  list  consists  of  two  parts,  those  being  a fixed-length  part 
followed  by  a variable-length  part.  The  fixed  part  of  an  element  always  consists  of  three 
words,  which  in  the  indicated  order,  contain  the  forward  pointer,  the  backward  pointer,  and 
the  time  when  the  element  was  added^o  the  list. 

LTDEFX  — Define  a List.  This  subroutine  creates  a standard  list  head  for  the  list  being 
defined  and  then  stores  in  it  information  which  defines  and  initializes  the  new  list.  It  returns 
a pointer  to  the  newly  created  list  head.  The  list-head  pointer  of  a doubly  linked  list  points 
to  a table  of  standard  format. 

LTADDX  — Add  an  Element  to  a List.  This  subroutine  adds  a new  element  (a  block 
stored  in  Dynamic  Memory  and  pointed  to  by  the  input  a^'gument  hkptr)  to  the  list 
identified  by  the  list-head  pointer  Itptr.  Addition  of  a new  element  is  done  by  properly 
linking  it  with  the  elements  already  in  the  list  and  by  modifying  the  list-head.  The  insertion 
position  relative  to  other  list  elements  is  determined  by  means  of  the  queueing  discipline 
code  of  the  list,  which  is  located  in  the  list-head.  Thus,  the  code  value: 

1.  LIFO  causes  the  new  element  to  be  added  to  the  logical  front  end  of  the  list, 

2.  FIFO  causes  the  new  element  to  be  added  to  the  logical  back  end  of  the  list, 

3.  LOHI  causes  the  new  element  to  be  placed  logically  in  front  of  the  first  element 
with  a rank  value  larger  than  that  of  the  new  element,  and 

4.  HILO  causes  the  new  element  to  be  placed  logically  in  front  of  the  first  element 
with  a rank  value  smaller  than  that  of  the  new  element. 

LTDMPX  — Dump  Contents  of  Linked  List.  This  subroutine  is  used  to  write  the 
contents  of  a Linked  List  according  to  a user-supplied  format. 

LTFIMDX  — Find  a Specified  Element  in  the  List.  This  subroutine  searches  the  list  in 
the  direction  of  the  decreasing  rank  of  its  elements  to  find  the  first  element  which  contains 
a specific  value  (not  necessarily  the  rank)  stored  in  the  specified  word  of  the  list  elements. 
On  finding  such  an  element,  the  subroutine  returns  a pointer,  clptr,  designating  this  element. 
If  none  is  found,  ciptr  is  assigned  a zero  return  value. 
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f I Th»‘  pointer  points  to  the  list-head  of  the  list  to  In*  searfhe<l.  I'he  type  of  the  test  value 

iJata  must  Ih*  the  same  as  that  of  the  testwl  quantity.  The  arfiument  speeifies  the  offset  of 
the  won!  m every  list  element  whose  value  is  to  he  eompared  with  that  of  cinta.  The  element 
found  hy  subroutine  LTFNDX  may  be  removed  from  the  list  by  a eall  to  subroutine 
l.TRSl'X. 

LTNXTX  — Return  the  Pointer  to  the  Next  (First)  Element  In  a List.  Given  the  pointer 
elptr  to  an  element  in  a spefifitxl  list,  this  subroutine  returns  the  pointer  to  the  element 
whieh  IS  logically  next  (i.e.,  which  is  of  the  next  lower  rank)  after  the  one  ^)ointed  to  by  tiie 
i’lptr.  If  the  user  sets  the  input  argument  elptr  to  zero,  then  the  routine  returns  the  pointer 
to  the  first  element  of  the  list.  If  .such  an  element  (first  or  next)  does  not  exist,  then  rixtpt 
has  a return  value  of  zero.  The  list  is  specified  by  its  list-head  pointer  Itptr.  The  element 
found  by  subroutine  LTNXTX  may  be  removed  from  the  list  by  calling  subroutine 
LTRSTX. 

LTRSPX  — Remove  a Specified  Element  From  a List.  I’his  subroutine  removes  the 
element  pointwl  to  by  the  pointer  elptr  from  a list  specifitnl  by  the  list-head  pointer  Itptr.  If 
elptr  is  set  equal  to  zero,  then  the  logically  first  element  is  removed.  This  subroutine  can  be 
ustnl  to  remove  elements  found  by  subroutines  LTFNDX  or  L TNXTX. 

2.3.6.4.3.4  Processing  of  Indexed  Lists  by  Means  of  LPC  Subroutines.  The  list-head  is  a 
vtvtor:  the  first  component  of  this  vector  contains  a counter  which  specifies  the  number  of 
elements  currently  in  the  list;  subsequent  components  of  this  vector  contain  the  pointers  to 
individual  elements  of  the  list.  The  user  communicates  with  the  indexed  list  through  the 
list-head  pointer. 

Four  subroutines  for  handling  indexed  lists  are  available.  These  subroutines  are 
described  next.  Contrary  to  the  case  of  doubly  linked  lists,  then'  is  no  special  subroutine  for 
initializing  an  indexed  list  (i.e.,  for  creating  the  list  head  for  such  a list);  this  is  done  by 
assigning  the  first  element  to  the  list  to  be  created. 

DSADDX  — Add  a New  Element  to  an  Indexed  List.  This  subroutine  adds  a new 
element  to  an  indexeil  list  identifie<l  by  the  list-head  pointer  Iptr.  The  element  to  be  added 
must  be  a block  ston'd  in  Dynamic  Memory;  the  input  (xjinter,  elptr,  must  l)e  pointing  to 
the  storage  area  of  that  element. 

DSDMPX  — Dump  Contents  of  Indexed  List.  This  subroutine  is  used  to  write  the 
contents  of  an  Indexed  List  according  to  a user  supplied  format. 
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DSNXTX  - Return  a Pointer  to  a Specified  Element  of  an  Indexed  List.  Subroutine 
DSNXTX  retrieves  the  pointer  elptr  to  the  jth  element  of  an  existing  (nonempty)  indexed 
list  which  is  identified  by  the  list-head  pointer  Iptr.  The  jth  element  is  specified  by  assigning 
J as  the  value  of  the  input  argument,  index,  where  1 J < N (where  N is  the  number  of 
elements  currently  in  the  list). 

DSPRGX  — Purge  an  Indexed  List.  This  subroutine  deallocates  from  Dynamic  Memory 
the  storage  blocks  occupied  by  the  list-head  and  by  all  elements  of  the  indexed  list 
identified  by  the  list-head  pointer  Iptr.  Then  the  subroutine  sets  the  pointer  Iptr  to  zero.  If 
the  subroutine  is  entered  with  a list-head  pointer  value  of  zero,  control  is  returned  to  the 
calling  program. 

2.3.6.4.4  Generation  of  random  numbers 

The  Random  Number  Generation  Component  (RNGC)  of  the  Basic  Simulator  provides 
the  user  with  subroutines  for  producing  sequences  of  random  numbers  from  nine  standard 
distributions  commonly  used  in  simulation.  In  addition,  it  contains  three  subprograms  for 
generating  random  numbers  from  continuous  or  discrete  distributions  defined  by  the  user. 

2.3. 6. 4.4.1  Furwtional  Description.  Each  RNGC  subprogram— with  the  exception  of 
the  generator  of  random  numbers  having  uniform  distribution  over  the  unit  interval 
(subprogram  RANDOX)— calls  RANDOX  to  generate  one  or  several  uniformly  distributed 
random  numbers  needed  for  computation  of  its  own  output.  Thus,  a sequence  of  random 
numbers  from  a nonuniform  distribution  always  represents  the  result  of  no  one  sequence  of 
random  numbers  from  a uniform  distribution.  The  first  number  is  such  a sequence;  Uq  must 
either  be  furnished  by  the  user  or  else  it  is  automatically  provided  by  the  Basic  Simulator 
during  standard  initialization  of  simulation. 

To  give  the  user  some  control  over  generation  of  the  sequences  of  uniformly  distributed 
random  numbers  which  are  to  be  used  to  generate  random  numbers  from  other 
distributions,  a labeled  COMMON  block  is  made  available  to  the  user.  Each  component  of 
the  vector  ISTART  is  associated  with  one  and  only  one  RNGC  subprogram:  initially,  it 
must  contain  the  seed  for  the  underlying  sequence  of  uniformly  distributed  random 
numbers;  subsequently,  it  is  used  to  store  the  generated  successors  of  that  seed.  It  is 
conceivable  that  the  user  may  want  to  use  the  same  generator  subprogram  to  produce 
several  sequences  concurrently  during  simulation.  This  can  be  done  by  using  an  appropriate 
component  of  the  vector  ISTART  to  store  the  values  associated  with  generation  of  each 
such  sequence.  To  summarize  the  above  ideas,  the  elements  of  vector  ISTART  contain  the 
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initial  (seed)  and  subsequent  values  that  are  used  to  propagate  each  needed  sequence  of 
uniformly  distributed  random  integers.  Some  sequences  of  this  type  do  not  show  up 
explicitly  in  simulation,  for  they  are  used  as  underlying  sequences  to  produce  random 
numbers  from  other  distributions;  the  others  are  used,  per  se,  in  simulation. 

The  Random  Number  Generation  Component  consists  of  the  following  subprograms: 

1.  RANDOX  — Random  Number  from  Uniform  Distribution  Over  the  Unit  Interval. 

2.  RMBINX  — Random  Number  from  a Negative  Binominal  Distribution. 

3.  RMCCPX  — Random  Number  from  a User-Defined  Discrete  Cumulative 

Distribution. 

4.  RMDCPX  — Random  Number  from  a User-Defined  Discrete  Cumulative 

Distribution. 

5.  RMDRWX  — Random  Number  from  a Bernoulli  Trial. 

6.  RMERLX  — Random  Number  from  an  Erlang  (Gamma)  Distribution. 

7.  RMEXPX  — Random  Number  from  an  Exponential  Distribution. 

8.  RMICPX  — Random  Integer  from  a User-Defined  Discrete  Cumulative  Distribution. 

9.  RMIUFX  — Uniformly  Distributed  Random  Integer  from  a Set  of  Consecutive 
Integers. 

10.  RMNRLX  — Random  Number  from  a Normal  Distribution. 

11.  RMPSNX  — Random  Number  from  a Poisson  Distribution. 

12.  RMUFMX  — Uniformly  Distributed  Random  Number  from  a Specific  Interval. 

All  these  subprograms  are  FORTRAN  FUNCTION  subprograms.  With  a single 
exception,  they  return  a single  output  quantity,  which  is  either  a single-precision  floating 
point  number  or  a standard-length  integer.  The  only  exception  is  RANDOX,  which  besides 
producing  a floating  point  random  number,  also  generates  an  integer-valued  uniform  random 
quantity.  The  use  of  each  subprogram  is  discussed  next. 

2.3.6.4.4.2  RANDOX  — Random  Number  from  a Uniform  Distribution  Over  the  Unit 
Interval.  Normally,  RANDOX  is  used  to  generate  a sequence  of  single-precision  floating 
point  values,  [U,j]  which  represent  random  numbers  uniformly  distributed  over  the  unit 
interval  [0,1] . The  secondary  use  of  RANDOX  is  to  produce  a sequence  of  random  integers, 
[1^1 , uniformly  distributed  over  an  interval  defined  by  the  computer  word  size. 

2.3.6.4.4.3  RMBINX  — Random  Number  from  a Negative  Binominal  Distribu- 
tion. RMBINX  computes  a random  number  from  the  negative  binominal  distribution  with 
parameters  (P,  N);  i.e.,  given  (1)  the  number  N of  successes  in  a sequence  of  independent 
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Bernoulli  trials  (i.e.,  each  trial  has  only  two  outcomes— a success  or  a failure)  and  (2)  the 
constant  probability  P of  success  in  each  trial,  this  subroutine  generates  the  number  of 
failures  before  the  Nth  success  is  observed. 

2.3.6.4.4.4  RMCCPX  — Random  Numbers  from  a User-Defined  Continuous  Cumulative 
Distribution.  Given  the  tabular  approximation 

(X(I),  Y(I))  for  I = 1,  2 N 

to  a cumulative  probability  distribution  function  y = F(x)  of  a continuous  random  variable 
X,  this  subprogram  computes  a random  number  XR  from  the  range  X (1)  < X(N). 

2.3.6.4.4.5  RMDCPX  — Random  Number  from  a User-Defined  Cumulative  Distribu- 
tion. Given  the  tabular  approximation 

(X(I),  Y(I))  for  1 = 1,  2, . . . ,N 

to  a cumulative  probability  distribution  function  y = F(x)  of  a discrete  random  variable  X, 
this  subprogram  computes  a random  number  XR  from  the  set  of  values  [X(1),X(2), 
....X(N)). 

2.3.6.4.4.6  RMDRWX  — Random  Number  from  a Bernoulli  Trial.  A Bernoulli  trial 
represents  an  idealized  experiment  which  can  have  only  two  observable  outcomes,  such  as  a 
success  and  a failure,  to  be  represented  here  by  1 and  0,  respectively.  Denote  the  probability 
of  a success  in  a trial  by  P;  then  the  probability  of  a failure  is  1 — P.  Given  the  probability  P 
of  success,  this  subprogram  returns  1 (=  success)  with  probability  P and  0 (=  failure)  with 
probability  1 — P.  The  value  of  the  input  argument  P must  be  in  the  range  0 < P < 1. 

2.3.6.4.4.7  RMERLX  — Random  Number  from  an  Erlang  (GAMMA)  Distribution.  This 
subprogram  produces  a random  number  XR  from  the  Erlang  (A,  N)  (or  equivalently  from 
the  gamma  (A,  N))  distribution.  Here,  the  positive  real  number  A is  the  mean  of  the 
distribution;  the  positive  integer  N specifies  the  number  of  independent  exponential  random 
variables,  each  from  the  exponential  distribution  with  the  mean  A/N,  whose  sum  represents 
a random  variable  from  the  Erlang  (A,N)  distribution.  Thus,  a random  variable  XR  from  this 

9 

Erlang  distribution  has  expected  value  E(XR)  = A and  variance  Var(XR)  = A /N. 

2.3.6.4.4.8  RMEXPX  - Random  Number  from  Exponential  Distribution.  This  subpro- 
gram computes  a random  number  from  the  exponential  distribution  with  parameter  A.  If 
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XR  represents  such  a random  number,  then  the  expected  value  E(XR)  = A and  the  variance 
Var(XR)  = A^. 


2.3.6.4.4.9  RMICPX  — Random  Integer  from  a User-Defined  Discrete  Cumulative  Dis- 
tribution. This  subprogram  computes  a random  integer  IR  from  a discrete  cumulative  distri- 
bution defined  by  the  user  over  a set  of  consecutive  integers.  Such  a distribution  can  be 
represented  by  a set  of  ordered  pairs. 

Z3.6.4.4.10  RMIUFX  — Unfiformly  Distributed  Random  Integer  from  a Set  of  Consec- 
utive Integers.  Consider  an  integer  valued  random  variable  X which  is  uniformly  distributed 
over  the  set 


lA,  lA  -t- 1 . . . , IB 

of  consecutive  integers;  that  is,  if  IB  — LA  = N — 1,  then 

P (X  = X)  = 1/N  for  X = lA,  lA  -H, . . . , IB 
P (X  = x)  = 0 for  all  other  values  of  x. 

Given  the  values  of  lA  and  IB,  this  subprogram  selects  a random  integer  IR  from  one  of  the 
N equally  probable  values.  lA,  lA  +1, . . . , or  IB. 

2.3.6.4.4.11  RMNRLX  — Random  Number  from  a Normal  Distribution.  This  subpro- 
gram computes  u random  number  from  the  normal  distribution  with  the  mean  value  .A  and 
with  standard  deviation  B. 

2.3.6.4.4.12  RMPSNX  — Random  Number  from  a Poisson  Distribution.  This  subpro- 
gram generates  a random  number  X from  the  Poisson  distribution  with  the  mean  value  A. 

2.3.6.4.4.13  RMUFMX  — Uniformly  Distributed  Random  Number  from  a Specified 
Interval.  This  subprogram  computes  a random  number  from  the  uniform  distribution  over 
the  interval  [L,  R] . 

The  values  of  L and  R must  satisfy  the  inequality  L < R. 

2.3.6.4.5  Processing  of  sample  statistics 

In  simulation  of  discrete-stochastic  systems,  a substantial  portion  of  the  output  observed 
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by  the  simulator  is  collectable  and  expressible  in  the  form  of  standard  sample  statistics,  such 
as  sample  means,  standard  deviations,  extreme  values,  or  frequency  distribution  tables.  This 
section  describes  the  subprograms,  collectively  known  as  the  Sample  Statistics  Processing 
Component  (SSPC)  of  the  Basic  Simulator,  whose  function  is  to  collect,  process,  and  dis- 
play, when  told  to  do  so,  standard  sample  statistics  for  specified  observable  phenomena. 


2.3.6.4.5.1  Functional  Description.  The  sample  statistics  which  can  be  obtained  during 
simulation  with  the  assistance  of  SSPC  subroutines  for  an  observable  phenomenon  consists 
of  summary’  data  and  of  an  optional  frequency  distribution  table.  The  latter  can  be  built  up 
in  several  alternative  modes.  The  statistical  summary  data  contain  sample  size,  mean,  stand- 
ard deviation,  and  range  (i.e.,  its  minimum  and  maximum  values).  The  frequency  distribu- 
tion table  shows  how  sample  values  are  distributed  over  a specified  set  of  continuous 
intervals. 

As  stated  below  in  the  description  of  SSPC  subroutines,  a frequency  table  can  be  built 
up  in  one  of  the  three  possible  modes,  the  difference,  normal,  or  time-weighted  mode. 
Furthermore,  an  entry  to  be  added  to  a frequency  table  may  optionally  be  multiplied  by  a 
weight  coefficient.  The  latter  option  is  available  only  for  the  first  two  modes  of  frequency 
table  construction,  the  difference  or  the  normal  mode. 

In  the  normal  mode  sampling  for  a frequency  distribution  table,  the  sampled  value  is 
first  weighted  by  a multiplicative  coefficient  (if  required— otherwise,  the  value  of  multiplica- 
tive coefficient  can  be  thought  of  as  being  equal  to  one)  and  then  added  to  the  proper 
interval  of  the  table. 

If  the  difference  mode  is  used  to  build  up  a frequency  distribution  table,  the  entry 
added  is  the  weighted  or  nonweighted  difference  (depending  on  the  weighting  option) 
between  the  current  sample  value  and  that  observed  the  last  time  This  sampling  mode  can 
be  used  to  study  distribution  changes  or  rates  of  changes  in  a recurring  phenomenon. 
Sampling  in  the  time-weighted  mode  is  performed  as  follows.  The  sample  value  to  be  added 
is  first  multiplied  by  the  amount  of  time  which  elapsed  since  the  last  sampling  instance  for 
the  frequency  distribution  table  under  consideration;  next,  this  time-weighted  value  is  added 
to  the  table  as  in  the  normal  mode.  Thus,  the  time-weighted  mode  can  be  used  to  study 
phenomena  such  as  the  distribution  of  storage  occupancy. 

Generating  and  displaying  a frequency  distribution  table  requires  three  functions.  First, 
the  table  and  the  other  sample  statistics  must  be  defined  and  initialized  at  the  beginning  of 


simulation.  Next,  each  timo  a quantity  to  l)e  added  to  the  table  is  Renerate<i  in  the  simula- 
tion pnicess,  its  value  mu.st  In*  examineil  to  find  the  appropriate  |)osition  (raniie  seKment)  of 
the  table  to  which  this  value  belongs  and  then  the  frequency  of  Uie  position  must  be 
incremented.  Similarly,  one  must  u|xlute  the  quantities  which  an>  lieing  generated  to  com- 
puU'  the  .sample  mean,  standani  deviation,  and  extreme  (minimum  and  maximum)  values. 
Finally,  at  the  end  of  simulation,  computation  of  the  above-mentionwl  statistics  must  Ih' 
completed  and  then  tlie  n'sults  must  be  displayed  by  writing  a computer-printed  reixirt.  The 
Sample  Statistics  I’rocessing  ('omponent  provides  three  subroutines,  descrilnnl  lielow,  to 
accomplish  these  thn>e  functions. 

2.3.6.4.5.2  SSPC  Subroutines.  The  Siunple  Statistics  Processing  C'omponent  consists  of 
the  following  three  sulmnitines: 

1.  TBDEFX  — Define/initialize  the  sample  statistics. 

2.  TBDATX  — Update  the  sample  statistics,  and 

;).  TBOin'X  — Complete  and  output  the  sampW'  statistics. 

At  the  beginning  of  a simulation  program,  the  user  must  call  TBUKFX  to  initialize  the 
statistics  collection  for  eacli  sample  in  which  he  is  intcn'.stcd.  Then,  as  .sample  observations 
lue  generated  during  a simulation  run.  the  subroutine  TBDATX  is  mpealedly  called  to 
accumulate  and  update  sample  statistics.  At  the  end  of  the  run,  TBOUTX  is  calU\l  for  each 
sample  under  consideration  to  complete  compulation  of  sample  statistics  and  then  to  out- 
put the  results.  The  use  of  each  .subroutine  is  disciussed  next. 

2.3.6.4.6  Error  diagnosis  and  reporting 

The  objective  of  the  Error  Diagnosis  and  Reporting  Component  (EDRC)  of  the  Basic 
Simulator  is  to  provide  the  u.ser  with  tools  for  debugging  his  simulation  program.  This 
component  consists  of  thme  basic  types  of  subroutines; 

1.  Those  for  providing  ext'cution  traces  and  for  writing  diagnostic  messages. 

2.  Those  for  clnvking  operational  panimeters  of  Uie  Basic  Simulator. 

,'l.  Those  for  printing  the  contents  of  data  slructun's  list'd  in  the  simulation. 

The  subroutines  of  type  two  are  not  diiectly  accessible  to  the  user  but  ate  seUvteil  by  a call 
to  the  debug  control  routine  (or  by  default). 

The  error  diagnosis  and  n'porting  routines  an'  descrilK'tl  below. 
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EDRC  Subroutines: 


2.3.6.4.6.1  DEBUGX  — Select  Debug  Control.  This  subroutine  is  us«hI  to  select  the 
level  of  piiriuneter  eheekinn  anil  exiH-ution  truce  in  the  Basic  Simulator.  It  may  Im*  cuIUhI  as 
often  ns  desired  during  the  simulation.  If  it  is  never  culleil,  default  values  an*  usihI. 

2.3.6.4.6.2  DIAGNX  - Write  a Diagnostic  Message.  This  subroutine  is  used  to  write  a 
diannostic  me,s.sai!e  and  to  optionally  terminut-'  further  execution. 

2.3.6.4.6.3  TRACEX  — Write  a User  Trace.  I’his  subroutine  is  used  to  write  a user  trace 
message  contamin^!  the  name  of  the  calling  routine,  the  simulation  time,  and  the  value  of  an 
iiiiHit  quantity. 

2.3.6.4.6.4  DSDMPX  - Write  Contents  of  Indexed  List.  This  subroutine  is  used  to 
write  the  contents  of  an  IndextHl  Li.st  acconlinK  to  a user  supplied  format. 

2. 3. 6.4. 6.5  LTDMPX  — Write  Contents  of  Linked  List.  This  siibnuitinc  is  useil  to  write 
the  contents  of  a Linked  Li.st  acconlini;  to  a user  supplied  format. 

2.3.6.4.6.6  MEMDPX  — Dump  Memory.  The  subroutine  MKMDI’X  can  lie  usihI  to 
dum|>  the  I'ontents  of  Dynamic  Memory  for  program  debuunmn  purposes,  t’allinn  this  sub- 
routine has  the  following  effect  ; The  contents  of  all  allocateil  blocks,  including  tlieir  block 
size,  will  be  printed.  The  block  size  and  pointer  fields  will  Ix'  printed  for  all  blocks  in  the 
Free  List.  I'lie  contents  of  those  blocks  that  cannot  be  identified  as  clearly  lieiiin  of  one  of 
the  two  types  (i.e.,  either  allocated  or  else  free)  will  be  printed  in  conjunction  with  error 
recovery  attempts.  Kach  wonl  will  be  printinl  both  as  a standard-length  intejjer  and  in 
machine  format. 

2.3.6.4.6.7  MSTATX  — Write  Memory  Statistics.  I'iie  subroutine  MST.Vr\  writes  the 
Dynamic  Memory  statistics  for  the  line  jirinter.  These  statistics  are: 

1.  The  size  of  the  memory  vector, 

2.  The  ma.\imum  number  of  wonls  which  were  allocateil  at  any  time  until  the  call  to 
MSTAT'X,  and 

3.  The  numlH*r  of  wonls  currently  allocatiHl. 

2.3.6.4.6.8  PKTPRX  - Write  Contents  of  Dynamic  Memory  Block.  This  subioutuie  is 
usixl  to  write  the  contents  of  a lilock  of  dynamic  memory.  The  block  is  printed  both  as  a 
standanl-leiiirth  inti'ner  and  in  machine  format 


2.3.6.4.6.9  PKTWRX  — Write  Contents  of  Dynamic  Memory  Block.  This  subnuitim'  i.s 
ii.'joil  to  wrilo  tho  oontontis  of  ii  block  of  dynamic  mcmor>’  ucconlinn  to  u user  supplied 
formal. 

2.3.6.4.6.10  RPWRTX  — Write  Data.  This  subroutine  is  u.setl  to  write  any  contijnious 
daUi  acconlinn  to  a user  supplied  format. 
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2.4  DISTRIBUTED  PROCESSOR/MEMORY  SYSTEM  NETWORK  SIMULATION  SYS 
TEM 

2.4.1  Introduction 

The  advent  of  the  minicomputer,  and  subsequently  the  microprocessor  and  microcom- 
puter, has  placed  a preat  deal  of  emphasis  on  the  utilization  of  multiple  computing  elements 
in  avionics  .systems.  The  relatively  small  size  of  minicomputers  and  microcomputers  allows 
them  to  perform  sptH-ialized,  localized  tasks  while  providing,  in  many  ca.ses,  added  perfor- 
mance over  more  general  purpose  computing  systems.  Multiplexed  data  buses  have  further 
providrKl  the  opportunity  for  computing  elements  to  sham  n*sources  and  to  provide  the 
redundancy  that  can  extend  system  operations  in  critical  situations. 

These  added  capabilities,  provided  by  what  may  be  ri'ferred  to  as  distributed  sysU'ms, 
present  the  sy.stem  designer  with  some  added  complexities  as  well.  Questions  regarding  how 
to  piulition  the  avionics  tasks  among  several  processors,  the  selection  of  the  an-hitecturt'  of 
the  processor  interconnections,  the  information  transfer  rales  Ivtween  processors,  the  coor- 


dination  of  information  transfer,  and  the  security  and  reliability  of  the  overall  system  arc 
more  difficult  to  answer  because  of  the  large  number  of  potential  system  configurations. 
Further,  the  basic  information  system  design  must  be  chosen  early  in  the  design  process  if  a 
top-down  design  approach  is  to  be  followed.  It  is  therefore  essential  to  be  able  to  explore 
the  basic  parameters  of  a distributed  processor  architecture  by  simulation  so  that  perfor- 
mance parameters  for  individual  processors,  sensors,  and  information  display  elements  can 
be  specified. 

The  Distributed  Processor/Memory  (DP/M)  System  Network  Simulator  (SNS)  provides 
the  necessary  tool  to  explore  some  of  the  tradeoffs  available  to  the  designer  of  distributed 
systems.  The  SNS  is  a discrete  event-oriented  high  level  traffic  simulator  written  in  ANSI 
standard  FORTRAN.  The  SNS  is  built  around  a nucleus  of  model-independent  utility  rou- 
tines (SIMNUC)  which  are  not  simulators  in  themselves,  but  are  used  to  create  a simulator  in 
conjunction  with  the  avionics  software  task  specifications  and  topological  organization  spec- 
ifications of  a given  avionic  system. 

2.4.2  OP/M  Hardware  Architecture 

The  DP/M  system  concept  is  essentially  the  use  of  varying  numbers  of  simple,  homoge- 
neous processor/memory  elements  (PE’s)  applicable  to  a wide  range  of  avionics  system 
processing  problems.  Architecturally,  these  PE’s  can  be  used  as  standalone  uniprocessors  or 
they  can  be  configured  in  a distributed  network  as  shown  in  Figure  2.4. 2-1.  Serial-time- 
division-multiplex  (TDM)  buses  interconnect  the  network.  Two  levels  of  busing  are  pro- 
vided: a Global  bus  can  interconnect  each  PE  in  a system  network  and  a Local  bus  can 
interconnect  multiple  PE’s  clustered  together  to  perform  a given  function.  This  cluster  of 
PE’s  is  referred  to  as  an  Affinity  Group  (AG).  Input/output  (I/O)  for  a given  P/E  to  an 
external  device  is  via  its  local  I/O  interface  unit.  While  other  more  complex  bus  structures 
might  be  postulated,  the  structure  provided  by  DP/M  allows  investigation  of  a number  of 
important  avionic  information  processing  and  control  structures. 

Although  it  is  not  necessary  to  know  the  structure  of  the  PE’s  in  order  to  use  the  SNS, 
such  knowledge  is  useful  in  order  to  appreciate  the  architectural  variations  possible  with 
DP/M  SNS  and  their  application  to  real  avionics  situations.  Four  functional  modules  make 
up  the  DP/M  PE  as  shown  in  Figure  2.4.2-1.  The  Bus  Interface  Unit  (BIU)  is  the  basic  TDM 
data  transfer  interface  to  the  processor  and  memory.  The  BIU  translates  bit  serial  data  into 
parallel  words  and  transfers  data  and  status  information  to  the  PE  processor  and  memory. 
The  processor  module  is  the  instruction-sequencing  and  data-processing  portion  of  the  PE. 
The  memory  module  provides  necessary  program  instruction  and  data  storage,  and  can  be 


Figura  2.4.2-1.  DP/M  system  architecture. 


accessed  by  the  other  PE  modules:  the  BIU,  the  processor,  and  the  I/O  interface.  Memory 
access  is  local  to  a PE;  i.e.,  access  by  another  PE  or  shared  memory  is  not  part  of  the  DP/M 
concept.  The  Input/Output  Interface  Unit  (lOIU)  of  the  PE  permits  digital  data,  command 
and  status  information  transfers  between  the  PE  and  the  external  devices  in  the  avionics 
system. 

An  example  of  the  type  system  envisioned  for  implementation  with  the  DP/M 
architecture  is  shown  in  Figure  2.4.2-2.  Note  that  the  structure  provides  for  a redundant 
Global  bus.  In  this  example,  two  Affinity  Groups  are  formed  by  PE3-PE4  and  PE5-PE6-PE7. 
Interface  to  sensors/effectors  is  illustrated  via  lOIU’s  in  the  PE’s  and  subsystem  interfaces 
external  to  the  DP/M  system. 

Z4.3  Bus  Control  Protocols 

2.4.3.1  Modified  Round-Robin  Message  Broadcast 

During  the  period  the  DP/M  SNS  has  been  in  use  at  AFAL,  two  bus  protocol  algorithms 
have  been  implemented.  The  first  is  a modified  “round-robin”  slotting  technique  which 


231 


Figure  Z4.2-2.  Example  OP/M  application. 


provides  for  simple  lulvancing  of  the  “bus  control  slot”  from  I’E  to  PE  in  a predeU'rmintxl 
order  amonc  the  total  set  of  PE’s  attached  to  tlie  bus.  Each  bus  transmission,  referred  to  as  a 
message,  is  terminated  by  the  transmittitig  PE.  Message  termination  is  denoted  by  placing  an 
end-of-message,  or  message-sync  signal  on  the  bus  immediately  following  the  last  data  bit  in 
the  message.  If  a PE  cannot  transmit  data  when  it  receives  bus  access,  it  merely  “passes” 
control  to  the  next  subsetpient  bus-controlling  PE  by  transmitting  on  the  message-sync 
signal.  A variable  length  message  may  be  transmitted,  although  the  maximum  length  of  a 
Global  bus  message  is  eight  daU»  words.  Messages  transmitted  by  any  PE  i-an  be  received  by 
any  other  PE,  since  PE’s  art'  always  in  a “listening”  mode  when  not  transmitting  (at  all  times 
other  than  its  bus  slot).  This  "broadcast”  metliod  is  implemented,  as  described  in 
subseiiuent  st'ctions,  by  providing  unique  input/output  message  designators  for  each  PE. 

2.4.3.2  MIL-STD  1553A 

The  second  bus  protocol  algorithm  implemented  by  DP/M  SNS  is  that  specified  by 
M1L-STD-1553A  (Aircraft  Internal  Time  Division  Command/Response  Multiplex  Data  Bus). 
The  basic  difference  between  tlie  1553 A protocol  and  the  round-robin  protocol  is  tliat  data 
transfers  occur  only  In'tween  two  PE’s,  one  specifically  designated  as  a transmitter  and  the 
other  as  a receiver.  Three  won!  formats  are  defined  for  tlie  protocol:  (1)  Command  won!, 
(2)  Data  word,  and  (3)  Status  word.  One  PE  must  be  designated  as  a bus  controller  as  shown 
in  Figure  2.4. 3-1.  Note  that  tlie  Remote  Terminals  (RT’s)  and  Bus  Controller  each 
correspond  to  a PE  in  tlie  architecture  of  Figure' 2. 4.2-1 . Sole  control  of  information 
transmission  on  the  bus  resides  witli  the  controller,  which  initiates  all  transmissions. 
’Fransmissions  are  performt'd  in  a half-duplex,  asynchronous  manner.  Three  message  formats 
an'  permitted; 

1.  Controller  to  RT  transfers, 

2.  RT  to  controller  transfers,  and 

3.  RT  to  RT  transfers. 

In  controller  to  RT  transfers,  the  controller  issues  a receive  command  to  an  RT  followed 
by  the  specified  number  of  data  words.  The  RT,  after  message  validation,  transmits  a status 
word  back  to  the  controller.  For  RT  controller  transfers,  the  controller  issues  a transmit 
command  to  the  RT.  After  command  verification,  the  RT  transmits  a status  word  liack  to 
the  controller  followed  by  the  data  words.  In  the  cast'  of  RT  to  RT  transfers,  the  controller 
issues  a receive  command  to  RT-A,  followetl  by  a transmit  command  to  RT-B.  The  RT-B 
then  transmits  the  same  format  as  in  controller  to  RT  transfers. 
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The  implementation  of  both  bus  protocol  schemes,  round-robin  and  1553A,  provides 
the  system  designer  with  the  opportunity  to  explore  some  basic  tradeoffs  in  bus  traffic 
overhead  versus  flexibility  and  assignment  of  executive  functions  to  PE’s,  among  others. 
Included  in  the  tradeoffs  are  the  inherent  architectural  differences  of  the  two  bus  protocols. 
The  1553A,  for  example,  does  not  allow  local  buses. 

2.4.4  Avionics  Software 

The  hardware  architecture  represents  one-half  of  the  distributed  avionics  system  design 
problem,  the  other  half  is  obviously  the  software.  The  DP/M  SNS  assumes  that  the  system 
designer  will  partition  the  executive  and  applications  software  into  suitable  tasks  for  some 
given  hardware  architecture.  The  SNS  then  provides  the  designer  with  the  capability  to 
analyze  and  evaluate: 

1.  Processing  element  characteristics/capabilities, 

2.  Number  of  resources  in  the  system, 

3.  Local  and  global  bus  configuration, 

4.  Inter-PE  communication  technique, 

5.  PE  Bus  protocol  communication  technique,  and 

6.  Executive  control  technique. 

2.4.4.1  Applications  Software  Functions 

The  SNS  is  predicated  on  the  representation  of  software  modules  by  a directed  graph, 
such  as  Figure  2.4.4.1-1.  A directed  graph  consists  of  a set  of  nodes  and  a set  of  directed 
edges  between  these  nodes.  A node  is  used  to  represent  a set  of  computations  which,  once 
initiated,  can  run  to  completion  without  waiting  for  completion  of  another  set  of 
computations  also  represented  by  a node.  An  edge  from  node  i to  node  j means  that,  upon 
completion  of  the  computations  represented  by  node  i,  the  computations  by  node  k can  be 
initiated.  The  implementation  of  a conditional  branch  in  this  model  is  accomplished  by  an 
exclusive-OR  symbol  0.  Use  of  the  symbol  in  conjunction  with  node  i implies  one  of  the 
following  conditions: 

Upon  completion  of  the  computations  associated  with  node  i,  only  one  of  the  set  of 

successor  nodes  can  be  initiated. 

Completion  of  only  one  of  the  nodes  associated  with  an  incident  edge  is  necessary  for 

initiation  of  node  i. 
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In  Figure  2. 4. 4. 1-1,  completion  of  node  1 indicates  that  no«.ies  2 and  3 can  be  initiated. 
Upon  completion  of  node  2,  either  node  4 or  node  5 can  be  initiated,  and  the  completion  of 
only  one  of  these  is  sufficient  to  initiate  node  7.  Node  8,  on  the  other  hand,  recpiires  the 
completion  of  both  node  6 and  node  7 for  its  initiation.  Stated  differently,  nodes  2 and  3 
are  successors  of  node  1,  and  nodes  6 and  7 are  predecessors  of  node  8. 

With  respect  to  avionic  mission  processing,  three  levels  of  directed  graphs  can  be  used. 
At  the  highest  level,  a node  represents  a mission-  or  pilot-oriented  function  such  as 
navigation.  For  any  given  function,  a set  of  nodes  or  options  may  exist  to  effect  the 
function.  These  nodes  are  referred  to  as  subfunctions  (e.g.,  navigation  modes  can  include 
inertial  navigation,  Loran,  or  doppler  navigation).  The  intent  of  the  subfunction  definition  is 
to  coincide  with  the  normal  division  and  classification  of  avionics  computer  programs.  At 
the  lowest  level,  a subfunction  is  represented  by  a set  of  related  tasks.  In  the  DP/M 
Executive  structure,  a task  represents  an  executable  application  software  module. 

The  representation  of  software  execution  sequences  via  a directed  graph  concept  has  a 
particular  advantage  within  the  DP/M  concept.  The  subfunction  directed  graph  nweals 
ix)tential  process  construction  options  in  allocating  tasks  and  program  to  PE’s.  If  any  one 
set  of  tasks  must  be  partitioned  among  several  PE’s,  the  options  available  in  allocating  this 
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software  to  PF^s  tire  clearly  defined  within  the  graph.  Data  sets  that  are  passed  from  one 
task  to  anotlier  represent  Local  bus  messages  if  their  respective  tasks  are  not  collocated  in 
the  same  PE.  Likewise,  collocated  tasks  need  not  generate  bus  traffic  with  their  data 
interchanges. 

The  software  task  representation  convention  usi>d  by  SNS  is  shown  in  Figure  2.4.4. 1-2. 

Each  task  is  assignetl  a unique  I.D.  number,  P-(N).  The  task  execution  time  must  Ih' 
estimated  from  knowledge  of  the  task  size  and  processor  speed  or  known  from  actual  tests. 
The  frequency  of  execution  (cycle  period)  is  also  specified.  All  intertask  information 
receivixl  by  the  task  remove  span'  or  generated  by  tlie  task  is  defined  in  terms  of  a message 
number  and  the  number  of  wonls  in  the  message.  In  addition,  local  I/O  is  also  specified  by 
the  number  of  words  in  the  message. 

The  DP/M  simulator  assumes  that  the  system  designer  will  partition  his  system  along  the 
lines  of  mission  functions  and  subfunctions,  although  this  need  not  necessarily  be  the  case. 
For  exam|ile,  such  a set  of  functions  might  be: 
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1.  Navigation, 

2.  Landing, 

3.  Air  Data, 

4.  Flight  Control, 

5.  Fire  Control, 

6.  Vehicle  Defense, 

7.  Stores  Management,  and 

8.  System  Management. 


These  functions  might  be  further  divided  into  subfunctions,  where  Navigation  might 
include: 


1 . Loran, 

2.  Inertial  strapdown, 

3.  Kalman  Filter, 

4.  Air  Mass, 

5.  Wind  Estimate,  and 

6.  Steering. 

The  Loran  subfunction  might  have  tasks  to  simulate: 
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Fifm  2.4.4.1-2.  OiraeitB  irafh  task  raprasMitation. 
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1.  Receiver  interface  (P-11 ), 

2.  Bearing  angle/expected  time  (P-12)  difference, 

3.  Time  difference  to  Lat./Long.  (P-13), 

4.  Delay  time  correction/velocity  information  (P-14),  and 

5.  Universal  Transverse  Mercator/Output  Display  (P-15). 

The  directed  graph  for  the  Loran  task  might  be  as  shown  in  Figure  2.4. 4.1-3. 


Fifurt  2.4.4.1-3.  Loran  wbfunetion  diroctod  inph. 
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2.4.4.2  Executive  Software 

The  use  of  distributed  Processing  Elements  (PE’s)  in  the  DP/M  system  concept  dictates 
the  need  for  a method  of  scheduling  activities,  transferring  bus  messages  between  PE’s  and 
general  system  control.  These  operations  are  referred  to  as  Executive  functions  and  are 
provided  by  the  SNS. 

The  subfunction  directed  graph  (Figure  2. 4. 4. 1-3)  contains  the  necessary  information 
from  which  the  Executive  can  determine  task-scheduling  conditions  (based  upon  required 
predecessor  events)  and  inter-task  communication.  Two  types  of  directed  graphs  can  be  used 
to  describe  avionic  functions:  the  sequential  graphs  and  the  parallel  graph.  A parallel  graph 
reveals  where  within  the  execution  segments  of  code  parallelism  can  be  used.  A sequential 
program  graph  removes  parellelism  and  shows  transition  paths  from  one  start  node  to  an  end 
node  with  multiple  nodes  emanating  from  a single  node  having  an  associated  probability  of 
transition.  Data  derived  from  other  types  of  graphs  can  be  used  to  derive  Executive  design 
parameters;  however,  the  Affinity  Group  (AG)  concept  is  most  effectively  used  when 
parallel  graphs  are  used  for  scheduling  purposes.  Another  desirable  feature  from  the 
Executive  design  viewpoint  is  to  allow  specification  of  the  size  of  a task  (i.e.,  number  of 
instructions,  words  of  memory,  execution  time)  to  be  flexible.  Ideally,  tasks  will  be 
identified  in  a way  to  encourage  increased  system  performance.  It  is  not  the  intent  of  the 
DP/M  Executive  design  to  require  a certain  (minimum)  number  of  tasks  to  be  created  for  a 
subfunction.  If  a subfunction  can  be  most  efficiently  controlled  by  the  Executive  as  a single 
task,  this  option  is  available.  If  a subfunction  has  a potential  (or  requirement)  for 
parallelism,  the  Executive  has  a method  of  facilitating  control  of  multiple  PE’s  executing 
code  for  the  different  tasks  of  the  same  subfunction.  It  follows  that,  as  avionic  subfunctions 
are  assigned  to  PE’s,  one  PE  will  contain  the  subfunction  start-node.  This  task  would  receive 
any  “subfunction  initiate’  commands,  and  start  the  execution  cycle  for  the  given  avionic 
software  algorithms. 

The  DP/M  Executive  structure  provides  two  levels  of  control:  the  Global  Executive 
(GEX)  and  the  Local  Executive  (LEX).  Functionally,  the  GEX  assumes  the  role  of  system 
monitor  and  scheduler.  It  enforces  subfunction  interrelationships  and  is  responsible  for 
system  performance  by  coordinating  those  software  programs  required  to  affect  mission 
avionic  functions  for  the  pilot  and  aircraft.  The  LEX  is  a PE-oriented  function  responsible 
for  sequencing  and  controlling  tasks  assigned  to  a PE.  The  LEX  is  concerned  with  scheduling 
those  tasks  assigned  to  its  PE,  based  upon  successful  satisfaction  of  all  the  tasks’  given 
predecessor  conditions.  The  Executive  control  hierarchy  for  DP/M  is  shown  in  Figure 
2. 4. 4. 2-1.  This  figure  does  not  represent  the  individual  routines  within  the  Executive;  rather, 
it  shows  the  inter-relationships  between  major  functions  in  the  executive  control  hierarchy. 
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SUBFUNCTION  ACTIVATE/COMPLETION 
MODE  MESSAGES  TIME 


Fiiur*  2.4.4,M.  ExMulivt  control  hiororchy. 


r 
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Tht*  Global  Extvutivo  initiates  a siibfunction  wlu'ti  all  the  svibfunotion  preiltvessor 
rtHiuirements  are  satisfitnl  and  whei\  it  is  time  for  it  to  run.  These  preileeessors,  in  adtiition 
to  start  time  wouk!  t>e  activation  messages  from  otie  or  more  other  siibfiinctions.  I'lie 
“initiate"  messajje  is  transmitted  by  the  GEX  to  tire  Local  Executive  on  the  Global  bus.  The 
Local  Executive  in  the  PE  which  contains  the  start  node  of  the  subfunction  ix‘co(jni/.es  this 
messjrge  and.  if  iiil  prt'decessors  to  that  start  mode  art*  satisfitni,  it  initiates  the  task.  The  task 
will  execute,  and  should  it  generate  a data  set,  it  will  call  the  i..KN  for  the  disposition  of  the 
data  set.  The  LEX  takes  the  nei'essary  actioti  to  rouU*  the  message  over  the  Local  rrr  Global 
bus  or  returns  control  to  the  task  imnuHliately  should  the  message  be  for  a tusk  co-n'siilent 
in  the  same  PE.  The  LEX  message  handler  always  n'leas''s  control  back  to  the  task.  When  a 
task  completes,  it  returns  control  to  the  Local  Executive,  and  the  cycle  n'peats.  Gnce  a 
subfunction  has  bet'u  time  initiated  by  the  Global  Exwutive,  it  will  run  to  completion  under 
the  contrt)!  of  the  Local  Executive(s).  Should  an  I/O  device  be  connected  to  a PE.  it  is  the 
responsibility  of  the  task  which  uses  this  I/O  device  to  control  this  I/O  ilevice.  This  does  not 
pr»K'lude  the  existence  of  a common  I/O  handler  routiire  which  is  ustnl  by  multiple  tasks. 

2.4.4.2.1  LEX  functional  design 


The  l)P/M  system  has  a homogenous  set  of  LEX  modules  in  each  PE.  The  relationship 
among  the  modules  of  the  I, EX  is  slrown  in  Figure  2.‘L4.2-2.  Each  LEX  initiates  tasks, 
honors  output  message  requests  from  tasks,  and  routes  messages  and  data  for  the  tasks.  Th»' 
LEX  is  table-driven,  thereby  maintaining  the  nuxluUur  nature  of  the  OP/M  system  ai\d 
providing  separation  of  system  logic  and  application  softwait'  modules.  A Local  Exivutive 
data  base  (or  the  LEX  tables)  in  each  PE  contains  all  information  pertaining  to  Uu'corrtvt 
initialization  and  control  of  the  tasks  within  that  PE. 

Major  routim's  found  in  the  LEX  include: 

1.  The  Bus  Interrupt  Service  Routines  which  service  interrupts  produceii  by  incoming 
messages  on  the  Local  and/or  Global  bus. 

2.  The  Task  Scheduler  composed  of  five  sub-modules  which  service  different  asiHvts  of 
the  scheduler  function.  The  Task  Scheduler  is  rt's^ransible  for  determining  which 
tasks  have  satisfied  their  predecessor  requirements  and  are,  hence,  ready  to  be  given 
control. 

3.  The  Dispatcher  module  which  transfers  control  to  the  highest  priority  task  in  the 
dispatcher  queue. 

•1.  The  Output  Message  InU'rpretor  module  which  is  calUxl  by  an  applications  task 
when  it  needs  output  message  service.  This  module  returns  control  to  the  task  after 
servicing  the  request. 
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INPUT  BUS  MESSAGE  INTERRUPT 


I TASK  I 


OUTPUT  MESSAGE  f \ 

COMPLETE— *1  5 j 

INTERRUPT  \.  J 


NODE  DEFINITIONS 

1 - BUS  INTERRUPT  SERVICE 

2 - TASK  SCHEDULER 

3 - DISPATCHER 

4 - OUTPUT  MESSAGE 

INTERPRETER 

5 - MESSAGE  TRANSMITTER 

6 - INTERVAL  TIMER  SERVICE 

7 - MONITOR 

8 - ERROR  DETECT/RECOVERY 


Fiiurt  2.4.4.2-2.  LEX  modul*  and  tatk  intarraittionihip. 


5.  The  Message  Transmitter  Module  which  is  invoked  by  the  Output  Message  Complete 
Interrupt  from  one  of  the  bus  interfaces.  The  module  is  able  to  output  data 
autonomously  over  the  appropriate  Local  or  Global  bus  should  such  a request  be 
postetl  in  its  service  queue. 

6.  The  Interval  Timer  Service  Module  which  is  invoked  when  a hardware  Programmable 
Internal  Timer  (PIT)  interrupt  occurs.  This  is  an  error  condition  indicating  that  a 
task  has  taken  too  long  to  complete.  The  module  returns  an  appropriate  status  to 
the  error  monitor  module  for  disposition. 

2.4.4.2.2  GEX  functional  design 

The  Global  Executive  schedules  time-dependent  subfunctions  in  the  DP/M  system.  A 
timt'-ordered  linktHl  list  provides  the  GEX  witli  the  relative  times  to  schedule  every 
time-ilependent  subfunction  in  the  system.  A “go"  message  is  generated  by  the  GEX  to  a 
subfunction  only  if  other  predecessor  conditions  for  the  subfunction  have  been  satisfied 
when  it  is  time  to  run  the  subfunction.  The  GEX  data  base  (or  tables)  contains  all 
information  pertaining  to  the  initialization  and  control  of  all  time-dependent  subfunctions 
in  the  DP/M  system.  Figim*  2.1. 1.2-3  diagram  of  routines  used  by  the  Global  Executive. 

The  GEX  Schixluler  is  invoked  by  an  interrupt  from  the  PIT.  The  scheduling  algorithm 
processes  a time-orden'd  linkeil  list  of  subfunctions  that  an*  candidates  for  schetluling  by  the 
GEX  schwhiler. 

All  the  LEX  modules  described  previousl"  form  a part  of  the  GEX.  Certain  GEX 
modules  such  as  the  Completion  Status  Monitor  and  the  Activate/ Deactive  subfunction 
monitor  can  be  scheduled  by  the  LEX  in  the  Glolxil  Executive  PE  in  the  same  manner  as  if 
they  were  application  tasks. 

The  Completion  Status  Monitor  module  of  the  GEX  is  si'heduled  to  run  when  a 
completion  message  is  received  from  a subfunction.  This  motlule  supplies  this  information 
to  the  GEX  scheduler. 

The  Activate/Deactivate  (subfunction)  Monitor  of  the  GEX  is  scheduled  when  an 
activate /deactivate  subfunction  message  is  received  over  the  Global  bus.  Like  the 
Completion  Status  Monitor,  the  activate/deactivate  monitor  supplies  this  information  to  the 
GEX  scheduler. 

The  Mode  Change  Detector  module  is  schedulixl  when  a mode  change  command  is 
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Fifun  2.4.4.2-3.  GEX  block  diagram. 


received  over  the  Global  bus.  A mode  change  command  provides  a quick  method  of 
initiating  a new  set  of  subfunctions  such  as  might  be  involved  when  the  pilot  selects  a master 
function  switch  on  a control  panel  and  causes  multiple  subfunctions  to  become  active. 

Z4.5  DP/M  SNS  Simulation  Control 

The  SNS,  being  constructed  of  SIMNUC  model  independent  routines,  has  the  same 
general  characteristics  as  SIMNUC  and  GASP  IV.  That  is,  SNS  is  a discrete  event-oriented 
simulation  system.  Unlike  a continuous  system  where  transitions  from  one  state  to  the  next 
are  a continuous  function  of  time,  transitions  from  one  state  to  another  in  a discrete  system 
occur  at  discrete  points  in  time.  Distinguishable  state  transitions  are  called  events. 


f 
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Event-orientwl  simulation  systems  emphasize  a detailed  description  of  the  steps  that  occur 
when  an  individual  event  takes  place. 


The  setjuence  by  which  this  event-oriented  simulation  takes  place  in  SNS  is  illustrated 
by  Figure  2. 4. 5-1. 


The  Simulation  Control  Algorithm  (SCA)  controls  simulation  time,  maintains  the 
Future  Events  List  (FED,  and  provides  any  ancillary'  system  routines.  The  heart  of  the 
simulator  is  the  Futm'  Events  List,  a chronologically  ordered  list  that  contains  event 
notices.  Associated  with  each  event  notice  is  an  activity  routine  that  simulates  the  actions  of 
the  particular  event  to  be  modeled.  The  SCA  removes  the  first  event  notice  from  the  FEL, 
advances  simulation  time  to  the  time  associated  with  the  event,  determines  the  activity 
routine  associated  with  the  event  and  passes  control  to  it.  Simulation  time  may  be  advanced 
to  the  time  associated  with  the  next  FEL  entity  since  the  FEL  is  chronologically  ordered; 
thus,  there  can  be  no  event  before  the  first  element  on  the  FEL.  Time  is  therefore 
determined  by  the  sequence  of  events  and  not  by  some  fixed  interval. 


FifM«  2.4.S-1.  Smiilation  control  ttnieturo. 
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Each  activity  routine  performs  essentially  the  same  task.  First,  it  destroys  its  event 
notice,  after  extracting  any  pertinent  information,  by  returning  it  to  dynamic  memory. 
Next,  the  activity  must  determine,  via  its  data  structures,  if  all  precedence  relationships  have 
been  satisfied.  If  not,  the  activity  is  placed  in  a waiting  queue  until  such  time  as  the 
constraints  are  satisfied.  If  all  constraints  are  satisfied,  the  activity  may  be  executed,  thus 
changing  the  state  of  the  system.  Necessary  statistics  are  then  gathered.  Finally,  a new  event 
notice  is  generated,  a time  for  the  event  to  be  executed  in  the  future  is  computed,  and  the 
next  event  notice  is  returned  to  the  SCA  to  be  placed  on  the  FEL.  The  SCA  then  removes 
the  next  event  from  the  FEL  and  proceeds  in  the  same  manner  as  before. 

2.4.6  DP/M  SNS  Reporting  Capability 

A family  of  data  collection  and  report  generation  programs  are  provided  with  the  DP/M 
System  Network  Simulator.  These  programs  provide  the  capability  to  selectively  collect  data 
on  and  generate  reports  for  the  various  system  parameters  under  investigation  for  a 
particular  DP/M  system  configuration  and/or  avionic  mission  segment.  Both  the  collection 
and  dispensation  of  data  as  well  as  the  generation  of  reports  are  controlled  by  user  specified 
parameters.  In  general,  the  user  has  four  options:  (1)  no  data  is  collected  and  no  reports 
g«ierated,  (2)  data  is  collected  and  saved,  but  no  report  generated,  (3)  data  is  collected  and 
report  generated  but  data  not  saved,  (4)  data  is  collected  and  saved,  and  reports  generated. 
Data  saved  on  magnetic  tape  may  be  processed  at  a later  time.  In  fact,  this  saved  data  may 
be  used  at  a later  time  to  compare  results  of  two  or  more  different  simulation  experiments. 
The  particular  options  available  are  discussed  in  detail  in  the  following  sections. 

Data  collection  and  report  generation  occur  at  three  distinct  levels:  (1)  event  level,  (2) 
sample  period  level,  (3)  post  simulation  level.  At  each  of  these  levels,  reports  concerning  bus 
performance,  processor  loading,  executive  performance,  and  number  of  avionic  tasks 
processed  may  be  selectively  generated. 

2.4.6. 1 Event  Level  Reports 

Event  level  reports  consist  of  those  reports  that  are  generated  at  the  completion  of  each 
simulation  event.  An  event  level  report  provides  a single  line  output  that  indicates  the 
current  event  execution.  These  reports  are  used  to  provide  an  event-by-event  trace  of  the 
flow  of  the  simulation  throughout  a particular  simulation  experiment.  For  example: 


EVENT  ROUTINE  “NAME”  AT  TIME  “NOW”  PROCESSING  “N 


is  an  event  level  report.  “NAME”  is  the  name  of  the  event  routine  currently  executing. 
“NOW”  is  current  simulation  time.  “N”  is  the  identification  of  the  entity  currently  being 
processetl  by  the  event.  N is  normally  an  avionic  task  or  message  identification  number. 

2.4.6.2  Sample  Period  Reports 

Sample  period  reports  consist  of  those  reports  that  are  generated  at  the  completion  of  a 
user  specified  sample  time.  Data  are  collected  during  a period  of  simulation  time  (sample 
period)  and  then  reports  (if  specified)  are  generated  at  the  completion  of  that  time.  Figure 
2.4.6. 2-1  is  an  example  of  a sample  period  report  for  a local  bus.  Figure  2.4.6. 2-2  is  an 
example  of  a sample  period  report  for  a processor.  The  user  may  specify  which  reports  are 
to  be  generated. 

In  all  report  examples,  times  are  measured  in  seconds.  A minor  frame  is  the  user  defined 
sample  period.  A major  frame  is  some  user  defined  sample  period  that  contains  an  integer 
number  of  minor  frames.  Message  numbers  are  those  identifications  assigned  by  the  system 
test  data.  Message  lengths  are  measured  in  bits  including  all  overhead  bits.  Origin  and 
destination  are  the  message  origin  and  destination  processor  identification  numbers.  Relative 
time  of  start  is  measured  from  the  start  of  the  minor  frame.  Bus  utilization  is  measured  as  a 
percentage  of  total  available  bus  bandwidth. 

2. 4.6.3  Post  Simulation  Reports 

Post  simulation  reports  consist  of  those  summary  type  reports  that  are  generated  after 
the  completion  of  a particular  simulation  experiment.  Post  simulation  reports  provide  a 
concise  summary  of  all  data  collected  throughout  the  simulation.  These  summaries  allow 
rapid  evaluation  of  simulation  results  without  massive  data  reduction.  If  after  initial 
evaluation  it  is  necessary  to  investigate  in  further  detail,  sample  period  or  even  event  level 
reports  may  be  utilized.  The  user  may  specify  explicitly  which  reports  are  to  be  generated 
even  though  data  were  collected  on  all  entities.  Figure  2.4. 6. 3-1  is  an  example  of  the  bus 
decomposition  report.  The  bus  decomposition  report  shows  the  relative  usage  of  the  bus 
bandwidth  by  each  component  of  a message.  Figure  2. 4. 6. 3-2  is  an  example  of  the  bus 
loading  bar  graph.  This  graph  shows  the  percentage  of  bus  utilization  during  each  sample 
period.  Figure  2. 4.6. 3-3  is  an  example  of  the  bus  utilization  summary  report.  This  report 
summarizes  the  performance  of  each  bus  in  the  DP/M  system  during  the  complete 
simulation  experiment.  This  report  is  actually  a summary  of  the  sample  period  bus  activity 
reports.  Also  associated  with  the  bus  usage  summary  is  a summary  of  all  messages 
transferred  over  that  particular  bus.  Figure  2. 4. 6. 3-4  is  an  example  of  the  message  utilization 
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Figure  2.4.6.2-1.  Sample  period  bus  report 
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Figure  2.4.6.3-4.  Message  transmission  summary  report 


summary  roport.  Reports  for  each  bus  may  Ih*  selected  by  the  user.  Figure  2. 4. 6. 3-5  is  an 
example  of  the  processor  utilization  bar  graph.  This  graph  shows  the  pen^entage  of  processor 
utilization  by  intermpt  servicing,  system  (executive)  programs,  and  example  of  the 
processor  utilization  summary  report  applications  programs.  Figure  2. 4. 6. 3-6  is  an  example 
of  the  processor  utilization  summary  report.  This  report  summarizes  the  utilization  of  eacli 
processor  in  the  DP/M  system  during  the  simulation  experiment.  This  report  is  actually  a 
summary  of  the  sample  period  processor  usage  reports. 

2.4.7  Simulation  Control  Namelist  Specifications 

The  u.ser  defines  the  architectim*  of  a given  system  to  the  DP/M  simulation  tlirough  a set 
of  namelist  specifications.  Simulation  output  information  desired  by  the  user  in  the  form  of 
reports  (as  described  by  Section  2.4.6)  is  specifunl  through  simulation  control  ciud  images. 

, The.se  specifications  lue  supplied  to  DP/M  in  the  following  order: 

1 

< 

j 1.  Report  Control  Sjx'cification  Data. 

\ 2.  Avionic  Task  Definition  Data, 

i 

‘ 3.  Bus  Performance  and  Connectivity  Definition  Datii, 

! 4.  Task  to  Prtjcessing  Klement  Assignment,  and 

5.  Subfunction  Scheduling  Definition  Data. 

Kach  of  the.se  input  specifications  is  briefly  described  below  for  the  case  of  tlie  round 
robin  bus  pmtocol  as  an  example  of  the  user  input  required  to  run  the  DP/M  SNS. 

2.4.7.1  Report  Control  Specification  Data 

The  card  images  for  run  control  and  report  printing  are  given  in  Table  2. 4. 7. 1-1.  Data 
iti  m.s  jire  .s«>lf-explanatory  except  for  the  following  notes: 

CanI  <*2  Fickl  #5  — This  flag  produces  a trace  print  and  memory  dump  of  internal  data 
•*  inUialuuluin. 

« **1  • I ►wUI  «6  Thes«»  numbers  control  a trace  print  each  time  an  event  routine  of 
PF  » cntentl.  Alh>ws  control  of  PE  number  1 thru  16. 

*5  I **•  I heM*  mimiM'rs  indicate  the  writing  mode  selector  for  tlie  various 

255 


L 


r 


^ • O • t • t ••••••  o * 

t-  o o 

• I I _ 


d • • • 


3 

<0  0.* 

1 a « 

oc 

4 • 

o 

< 

< 

4 

4 

4 

« 

«/t 

< 

< 

4 

4 

4 

N « 

V/) 

< 

< 

4 

4 

4 

• 

Ol 

< 

4 

4 

4 

4 * 

o 

< 

< 

4 

4 

4 

• 

% 

o 

< 

< 

4 

4 

4 

* 

t 

ac 

c 

9 < 

t 4 

• < 

♦ < 

f < 

• c 

!>  » 

a X 

C < 

4 

4 

4 

4 

r • 

5 

a 

< 

4 

4 

4 

4 

X • 

a:  < 

< 

4 

4 

4 

4 

4 • 

s 

O oc 

< 

4 

4 

4 

4 

ec  m 

{j 

UL  O 

< 

4 

4 

4 

4 

O • 

.H 

< 

4 

4 

4 

4 

a « 

'P 

»-  z 

< 

4 

4 

4 

4 

OL  • 

a 

ae  O 

< 

4 

4 

4 

4 

a.  • 

o •• 

< 

4 

4 

4 

4 

« 

3 

a ». 

C3  < 

• < 

• < 

t 4 

• < 

# c 

9 «/>  • 

a 

UJ  < 

r>t  < 

4 

4 

4 

4 

(MX* 

« IM 

1 < 

4 

4 

4 

4 

Ui  • 

M 

1 < 

4 

4 

4 

4 

»-  * 

Z -i 

1 < 

4 

4 

4 

4 

t/9  « 

O « 

1 < 

4 

4 

4 

4 

>•  • 

id 

1 < 

4 

4 

4 

4 

tA  • 

W 

»-  3 

I tA 

V/) 

i/9 

%A 

• 

rJ 

4 

1 */» 

%A 

1/) 

»/> 

N • 

*<4  t- 

1 wt 

iA 

iA 

*/» 

• 

a 

— Z O J 

9 • 

• • 

• • 

f • 

• c 

9 (A  • 

.r 

UJ 

o 

o 

o 

o 

o 

o 

o o o 

O I 

1 

M 

o 

4 

o 

4 

o 

4 

o 

4 

o 

4 

o 1 

1 

X 1 • 

t 

• 

f 

9 

9 

9 

• 

« 

• 1 

1 

3 

UJ 

1 -- 

o 

o 

•>4 

o 

04 

o 

04 

o 1 

1 

a 

1 UN 

m 

u> 

lA 

lA 

UI 

Ui  X 

1 

u 

t/^  Ui 

1 

04 

4 >- 

O 

o 

o 

o 

o 

o 

o 

o 

o 

o 

> 

O 3 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

X 

a 

UJ 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

UJ 

^ X 

X 

o 

u> 

o 

o 

u^ 

o 

lA 

o 

iA 

lA 

lA  O 

fti4 

o 

o 

rg 

rg 

ro 

r»> 

4 

4 1 

1 

UI  O 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

H* 

f 

• 

• 

• 

« 

• 

f 

• 

• 

• 

a 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

3 

z 

X 

O 

X 

M 

1 

1 UI 

4 

z 

-J 

z 

<Ni 

4 

sTi 

>o 

r>- 

flO 

O' 

o 

art 

3 Ui 

•a 

X X 

x 

• 

<-  4 

lA  X 

3 1 

«4 

^4 

04 

04 

04 

04 

•ia 

UL 

4 

X 

X 

a 

o • 

t 

• 

• 

• 

t 

9 

• 

• 

• 

t 

• 

• 

THIS  FACE  IS  BEST  iJVALlTY  rKACi'i--^ 
V'HvtM  CvXi'y  EUl\MSlUiU  TV  UUC 


^ o 

o 

^ o 

«0  lA 

Ai  CO 

N.  O 

lA  UJ  • 

O O I o 


• <0^0^ 
O O A* 
• • • • 

O lA  •#  Al 
tSI 


anal 


z z z 7 

UJ  Ui  UJ  Ui 

u u o u 
u ec  et  ac 

lU  Ul  O)  Ul 

a & a.  a 


too 


o I a 

OC  I lU 
a I ac 
I 

ac  I 
O I 
u.  I 
I 


lU  ae  I 
lA  Ui  I I 

< ►“  I ' 

o o 

a. 

*-  X 1 a 

iA  3 I 

ai  o I iu 

►-  I X 
I « 

Z I H 
a I 
•«  I ►- 
H I a 

< I < 


o o o 

O O N- 
A-  't  <0 
AJ  O 
O <M  O 
O O O O 

t t • t 

o o o o 


uj  a a N a a 

M Ui 


tU  X I 
X < 

M ac 
►-  o 
o 

X oe 
< CL 

ac 

I O iA 

i o z 
X o 

CL  — VU 

L-  X 

i CA  < •—  I 
X O t-  I 


< o o 
*-  z z 

< « « 
0X0 

o o 
z o ►- 

•-4  M o 


< I < lu 

J I L*  U.  ►- 

O I «A  o z 


s IhI 

(A  I dC  I 

I o 

X I a I 
a I UI  I 

O t I OC  I 


CO  < 

X K 
D O 
t Z K 


»-  _i  UI 
tA  a ^ 

>•  a o 

iA  < M 

~l  ^ ^ 
< < < 
L*  L>  L> 

COO 


j o o 

I z z 

I « — 

x o 
o o 
o ►- 
z o 
“ o 


> < 


• 9 


TABLE  2.4.7.M.  REPORT  CONTROL  SPECIFICATION  DATA 


Columns 


Oescription/Value 


CARDol 

1 

1-8 

L 

A8 

CARD  NAME  "'CONTROL' 

2 

910 

R 

12 

CARO  SEQUENCE  # = 01 

3 

1M2 

2X 

4 

13-80 

L 

17A4 

RUN  ID/DESCRIPTION 

CARD  #2 

1 

1-8 

L 

A8 

CARO  NAME  = 'CONTROL' 

2 

9-10 

R 

12 

CARD  SEQUENCE#  =02 

3 

11-12 

2X 

4 

13-24 

L 

3A4 

ADDITIONAL  RUN  ID 

5 

25-30 

R 

15 

DEBUG  CONTROL  FLAG 

(•1.TRUE) 

6 

31-35 

R 

15 

7 

36-40 

5X 

8 

41-50 

R 

no 

SIMULATION  START  TIME 

9 

51-60 

R 

no 

SIMULATION  END  TIME 

CARD  #3 

1 

1-8 

L 

A8 

CARD  NAME  •’CONTROL' 

2 

9-10 

R 

12 

CARD  SEQUENCE  #>03 

3 

11-20 

10X 

4 

21-36 

R 

1611 

5 

37-40 

4X 

6 

41-56 

R 

1611 

STCFLG  FLAGS 

7 

57-60 

4X 

8 

61-76 

1611 

WRC  FLAGS 

0 = No  print,  no  write  to  output  file 

1 = Print 

2 = Write  to  output  file 


i 3 = Both 


The  columns  are  assigned  to  output  reports  as  follows: 

61  — Sample  Period  Bus  Report 

62  — Sample  Period  Processor  Report 

63  — Event  Level  Report 

64  — Bus  Decomposition  Report 

65  — Bus  Utilization  Summary  Report 

66  — Message  'lYansmission  Summary  Report 

67  — Processor  Utilization  Summary'  Report 

68 

. — Not  Used 

76 

Observe  that  cards  1 and  2 identify  the  run  and  control  the  dump  of  initialization  data.  Card 
3 controls  the  data  collection  and  report  printing. 

2.4.7. 2 Avionic  Task  Definition  Data 

Software  tasks  and  their  relationship  to  one  another  in  terms  of  the  directed  graph  and 
message  stnicture  described  in  Section  2.4.4  are  specified  by  namelist  data  sets.  All  symbols 
start  in  column  2 of  the  data  card  image.  Variable  list  values  must  be  separated  by  commas 
with  no  imbedded  blanks.  Order  within  the  namelist  data  sets  is  not  important.  Those 
variables  with  default  values  are  optional  and  may  be  omitted.  The  namelist  data  items  are 
given  in  Table  2. 4. 7. 2-1. 

Additional  Executive  Modules  can  be  added  to  the  SNS  by  defining  them  as  tasks.  In 
order  to  do  so,  executive  modules  are  defined  by  task  definition  data  sets  as  described  by 
Table  2.4.7.2-1,  task  to  PE  assignment  data  sets  as  defined  by  Table  2. 4. 7. 4-1,  and,  if 
necessary,  subfunction  scheduling  data  sets  as  shown  in  Table  2.4. 7. 5.1. 


n 

i 

i 


TABLE  2.4.7.2-1.  AVIONIC  TASK  DEFINTION  DATA 

Variable 

Description 

Default 

Value/Restrictions 

At  many  of  the  following  data  sets  at  tbera  are  tasks; 

STOEFN 

Start  namelist  deta  set  descriptor 

LAST 

=.True.  If  last  task  definition 

TASKIO 

Task  identification  number 

NPREO 

Number  of  predecessors  to  task 

O32 

DELTA 

Inverse  of  rep.  rate  (period) 

2 -1 

TNAME=40H 

Description  of  task  (up  to  40  characters) 

Blanks 

NUMSUC 

Number  of  successor  tasks 

0 

SRID 

List  of  successor  tuk  IDs 

RTYPE 

16-bit  words  of  memory  used 

NUMBS 

Number  of  run  time  branch  successors 

0 

BSID 

List  of  run  time  branch  successors 

NIMSG 

Number  of  input  message  required  by  task 

0 

IMTYPE 

List  of  input  message  types 

XTIME 

Tasks  execution  time  in  processor  clocks 

0 

SEND 

End  namelist  data  set 

SMTBO 

Start  namelist  data  set 

NUMMSG 

Number  of  output  messages  generated  by  task 

SEND 

End  namelist  data  set 

As  many  of  the  following  namelist  data  sets  as  specified  by  NUMMSG ; 

SMOEFN 

Start  namelist  data  set 

TYPE 

Message  type 

0 

LENGTH 

Message  length  in  words  exclusive  of  overhead 

0 

NUMDES 

Number  of  destination  tasks 

0 

TASKID 

List  of  destination  tasks 

PHASE 

Transmission  time 

0 

PERIOD 

Period  of  message  transmission 

1 

PRTY 

Priority  of  message 

0 

CCLEN 

Control  length 

17 

SOURCE 

Source  ID 

0 

DENS 

Density 

0 

SEND 

End  namelist  data  set 
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2.4.7.3  Bus  Performance  and  Connectivity  Definition  Data 


r 


Specification  of  the  number  of  processing  elements  (PE’s)  in  the  system,  their 
identification  and  the  bus  performance  is  defined  by  user  as  in  Table  2.4. 7.3-1.  Affinity 
groups  are  specified  similarly  as  shown. 

2.4.7.4  Task  to  Processing  Element  Assignment 

Tasks  to  be  executed  by  each  processing  element  are  assigned  task  by  task  as  depicted  in 
Table  2.4.7.4-1.  The  order  of  task  execution  in  a given  processor  is  resolved  by  the  processor 
executive  based  on  predecessor/successor  relationships  defined  in  Section  2. 4. 7. 2. 


TABLE  2.4.7 .3-1.  BUS  PERFORMANCE  AND  CONNECTION  DEFINITION  DATA 


Variable 

Default  Value 

SGBOEF 

TOTPE 

= 

Total  number  of  PE's  in  DP/M  System 

GBCL 

List  of  PE  numbers  that  define  the  global  bus  connectivity 
in  the  order  for  control  to  be  passed. 

BLGTH 

= 

Total  number  of  elements  in  GBCL 

WSIZE 

Bus  data  word  length  (equal  to  the  sum  of  processor  data 
word  length  plus  error  checking  code  length  plus  data 
word  sync  length) 

16 

BITPRD 

= 

Bus  bit  period  (sec/bit) 

1 

MSYNC 

s 

Message  sync  signal  length  (bits) 

3 

GAPTME 

= 

Inter-message  gap  time  (sec) 

5 

SEND 

One  set  for  each 

affinity  group  to  be  defined; 

SLBDEF 

NUMPE 

3 

Number  of  PE's  in  this  affinity  group 

PECON 

s 

List  of  PE  numbers  that  define  the  local  bus  connactivity 

In  the  order  for  control  to  be  passed 

BLGTH 

3 

Total  number  of  elements  in  PECON 

LAST 

3 

.TRUE.,  use  if  last  affinity  group  definition 

SEND 
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TABLE  2.4.7 .4  1.  TASK  TO  PROCESSING  ELEMENT  ASSIGNMENT  DATA 


One  set  for  each  processor  assignment  to  be  defined; 


SOEFINE 

PEIO 

NUMTSK 


Processor  ID  having  tasks  assigned  to  it 

TASKS 

Number  of  tasks  to  be  assigned  to  the 

LAST 

processor 

send 

List  of  tasks  IDs  to  be  assigned  to  the  processor 

.TRUE.,  use  if  this  is  last  processor  assignment 
definition 
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TABLE  2.4.7.5-1.  SUBFUNCTION  SCHEDULING  DEFINITION  DATA 


As  many  of  the  following  data  sets  as  there  are  subfunctions: 


SFNDEFN 

Start  namelist  data  set  descriptor 

SFPE 

ID  of  PE's  with  subfunction  start  mode 

RUNT 

Time  at  which  subfunction  gets  first  'go'  message  (fis) 

LAST 

=.TRUE.  If  last  subfunction  definition 

ITER 

Iteration  period  of  subfunction  (ms) 

ID 

Numeric  identity  of  subfunction 

NUMPE 

Number  of  PE's  with  subfunction  starting  mode 

SEND 

2.4.7.5  Subfunction  Scheduling  Definition  Data 

Subfunction  scheduling  definition  allows  time-dependent  subfunctions  which  are  to  be 
scheduled  by  the  global  executive  to  be  defined  as  entries  in  a time-ordered  list.  Namelist 
specifications  are  given  in  Table  2.4. 7. 5-1. 

SECTION  2.4  BIBLIOGRAPHY 

Consolver,  G.,  et  al.,  Distributed  Processor/Memory  Architecture  Design  Program,  Texas 
Instruments,  Inc.,  Feb.  1975,  AFAL-TR-75-80.  > 

Texas  Instruments,  Inc.,  User's  Manual,  Computer  Program,  DP/M  System  Network 
Simulation  System,  Feb.  1975,  Code  Identification  No.  96214,  Unpublished. 
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Z5  SOFTWARE  DESIGN  AND  VERIFICATION  SYSTEM  (SDVS) 


Z5.1  SDVS  Objectives 

The  Software  Design  and  Verification  System  provides  necessary  non-real-time  software 
tools  to  aid  in  the  development,  testing,  verification,  and  maintenance  of  avionic  mission 
software.  The  SDVS  was  created  as  an  integral  part  of  the  Digital  Avionic  Information 
System  (DAIS)  program,  and  an  understanding  of  the  utility  of  SDVS  is  aided  by  an 
understanding  of  the  objectives  of  DAIS.  The  DAIS  concept  proposes  that  the  processing, 
multiplex,  and  display  functions  of  avionic  systems  be  common  and  service  on  an  integrated 
basis  all  of  the  usual  subsystem  functions  such  as  navigation,  weapon  delivery,  stores 
management,  flight  controls,  and  communications.  The  DAIS  program  has  atten  ed  to 
demonstrate  the  feasibility  of  this  concept  in  order  to  eliminate  some  of  the  proliferation  of 
non-standard  avionics  and  permit  the  Air  Force  to  assume  the  initiative  in  the  specification 
of  future  Air  Force  avionics. 

Since  the  use  of  common  hardware  and  software  for  acquisition  of  sensor  data, 
processing  of  information,  and  provision  of  display  information  is  critical  to  the  DAIS 
concept  (or  to  any  other  computer-oriented  system  concept),  the  software  design  and 
verification  functions  in  the  context  of  any  particular  processor  architecture,  are  vital  to 
success.  The  SDVS  thus  assumes  a vital  role  in  the  design  of  future  avionics  systems.  The 
following  description  attempts  to  describe  SDVS  in  a general  context  rather  than  entirely 
within  the  DAIS  framework,  since  it  has  a broad  applicability  to  avionics  system  design. 

2.5.2  SDVS  Overview 

The  design  of  the  SDVS  is  based  on  the  program  hierarchy  shown  in  Figure  2. 5.2-1. 
Note  that  the  DEC  system-10  operating  system  and  utility  routines  are  utilized  by  the 
SDVS.  All  of  the  SDVS  programs  are  arranged  in  three  levels.  A program  can  be  called  only 
by  a program  of  a higher  level,  and  it,  in  turn,  can  call  only  programs  at  a lower  level. 
Programs  on  the  same  level  have  no  direct  interface  and  must  pass  information  through  a 
program  at  the  next  higher  level.  The  SDVS  is  written  primarily  in  the  JOVIAL-73  language 
and  employs  structured  programming  techniques.  Other  source  languages  are  Cobol  and 
Fortran. 

The  SDVS  Control  and  Software  Management  Programs,  though  shown  at  the  top  of 
the  hierarchy,  are  actually  a collection  of  utility  routines  that  are  used  by  all  the  second 
level  programs.  The  exception  is  the  SDVS  Control  Program  function  that  interacts  with  the 

f 
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Figure  2.5.2-1.  Hierarchy  of  SDVS  software. 


user  and  selects  the  mode  of  operation.  The  hierarchy  diagram,  as  drawn,  n'presents  a 
functioniil  organization  rather  than  the  exact  control  interfaces  l)etween  the  various  pro- 
grams. A brief  statement  of  the  function  of  each  of  the  programs  follows. 

2.5.2. 1 SDVS  Control  Program  (CP) 

This  program  interacts  with  the  user  in  determining  the  desired  mode  of  operation  tmd 
then  transfers  control  to  the  appropriate  second  level  routine.  All  host  processor  functions 
are  performed  by  this  program  (I/O  handling,  calling  the  system  compiler,  etc.)  and  are 
bastxl  on  conversational  commands  input  by  the  user  from  the  File  Generation  mode  and 
from  second-level  program  requests.  It  will  also  submit  simulation  mns  into  Uie  batch 
system. 

2.5.2.2  Software  Management  Program  (SMP) 

This  program  maintiuns  and  provides  controlled  access  to  all  SDVS  files.  It  provides  the 
capability  to  store,  retrieve,  interrogate,  and  protect  these  files  by  building  and  maintaining 
file  catalogs  containing  information  about  the  files.  Examples  of  such  information  ait'  user 
file  name,  internal  file  name,  file  type,  program  version  number  and  revision  number, 
creation  date,  security  lock,  and  author. 

To  manipulate  effectively  the  File  Management  data  l>ase,  this  program  performs  thrtv 
major  processing  tasks  as  follows: 

1 . File  Retrieval  — Whenever  a file  from  tlie  File  Management  data  base  is  required  by 
one  of  the  SDVS  programs,  the  SMP  will  lie  invoked  to  retrieve  Uie  file  via  the  SDVS 
Control  Program.  It  will  use  the  retrieval  data  supplied  to  it  to  interrogate  its  file 
catalogs  and  locate  the  internal  name  of  the  requesteil  file.  This  internal  name  will 
lie  passed  to  the  SDVS  CP,  which  will  use  it  to  actually  locate  and  retrieve  the  file 
from  secondary  storage. 

2.  File  Disposition  — W’hen  a new  file  is  created  by  an  SDVS  program  or  a user,  it  must 
be  placed  in  the  File  Management  data  base  under  control  of  the  SMP.  The  progrtmi 
which  generates  the  file  (e.g..  Scenario  Generator,  Simulation  Control,  etc.)  issues  a 
file  creation  request.  This  request  contains  the  qualified  name  under  which  the  file  is 
to  be  controlled,  the  file  type,  and  the  name  of  the  jH'rson  resjionsible  for  the  file. 
The  request  is  passed  to  the  SMP  where  the  data  containt'd  in  the  request  is  used  to 
create  a new  catalog  entry  for  the  file.  The  cataloged  file  is  then  written  to 
swondary  storage  by  the  SDVS  CP. 
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3.  File  Protection  — The  third  major  function  of  the  SMP  is  to  provide  security  locks 
on  the  files  such  that  a given  file  can  only  be  accessed  by  someone  possessing  the 
matching  security  key.  Each  programmer  has  security  protection  over  his  files  until 
his  software  has  been  completely  testetl  and  is  ready  to  l)ecome  part  of  the  official 
system.  However,  the  project  manager  always  has  read-only  access  to  all  files  in  the 
daUr  base. 

2.5.2.3  File  Generator  (SWG) 

This  program  processes  file  manipulation  commands  input  by  the  user.  The  following 
commands  illustrate  some  of  the  functions  provided: 


I 


4 


I 

i 


HELP  - 

.-\CCESS  - 

EDIT  - 

TRANSLATE 
COPY  - 

NEXT-VERSION  - 


PRINT 

CREATE 

ENTER 

OUTPLT 


List  the  format  of  all  SDVS  user  commands 

Make  available  a specific  file,  version,  revision  for  processing 

Perform  text  editing  on  a file 

Compile  a J73  program 

Copy  a file  onto  another  file  name 

Generate  a new  version  from  the  previous  revision  of  the  version 
specified 

Print  a file  on  the  system  hard  copy  device 
Create  a new  file 

Enter  a file  from  the  host  computer  into  the  SDVS  catalogs 
Output  a file  from  SDVS  to  the  host  computer 


The  File  Generator  does  not  actually  perform  these  functions  itself  (e.g.,  TRANSLATE, 
EDIT,  ACCESS,  etc.),  but  rather  passes  the  user’s  requests  to  the  SDVS  Control  Program 
which  passes  them  to  the  DECIO  monitor  and/or  the  Software  Management  Program. 


2.5.2.4  Scenario  Generator  (SCG) 


This  program  is  divided  into  two  program  translators,  a Simulation  Control  Language 
(SCL)  translator  and  a Data  Processing  Language  (DPL)  translator.  The  SCL  defines  the 
user’s  simulation  scenario  to  be  executed;  the  DPL  defines  the  data  processing  to  be 
performed  on  simulation  data.  The  SCG  is  executed  by  a conversational  command  to 
translate  either  an  SCL  or  DPL  file.  The  Scenario  Generator  retrieves  the  desired  file  from 
the  SMP  catalogs,  translates  the  source  code,  and  catalogs  the  translated  test  case  in  the  SMP 
catalogs. 
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2.5.2.5  Simulation  Control  (SCP) 


These  programs  are  used  to  sequence  a simulation  scenario  defined  by  a translated  SCL 
program.  They  initialize  the  nece.esary  simulators  (ICS,  SLS,  data  bus,  environment)  for 
j execution,  load  the  users  mission  software  to  be  tested,  perform  rollbacks,  and  execute  a 

simulation  by  invoking  the  various  simulators. 

2.5.2.6  Post  Run  Edit  (PRE) 

The  Post  Run  Edit  program  provides  the  user  with  tlie  ability  to  analyze  the  data 
. recorded  on  a Rough  Output  Tape  (ROT)  during  a simulation  run.  The  Post  Run  Editor 

accesses  the  user-specified  translated  Post  Run  Edit  directives  file.  The  directives  specify 
what  data  is  to  be  selected  from  the  ROT,  what  analysis  is  to  be  run  on  that  data,  what 
format  is  to  be  used  to  display  the  analysis  results,  what  user  routines  are  to  be  used,  and 
what  devices  are  to  receive  the  output  files  created  by  the  Post  Run  Editor.  The  Post  Run 
1 Editor  provides  tabular  printouts,  interactive  displays  and  data  plots  based  on  user 

’ directives.  An  important  feature  is  the  ability  for  a user  to  write  an  analysis  routine  in 

JOVIAL  and  have  it  execute  within  the  framework  of  the  Post  Run  Editor. 

i 2.5.2.7  DAISSimulatorsdCS,  SLS,  DBS,  EES) 

1 

f 

The  programs  simulate  the  DAIS  hardware.  Each  of  these  programs  simulates 
appropriate  events  (e.g.,  execution  of  an  instruction,  a bus  transmission)  upon  direction  of 
the  Simulation  Control  Program.  The  programs  are: 


ICS  - 

Interpretive  Computer  Simulator 

SLS  - 

Statement  Level  Simulator 

DBS  - 

Data  Bus  Simulator 

EES  - 

External  Environment  Simulation 

While  the  first  three  of  these  particular  simulations  have  been  written  particularly  to 
simulate  the  DIAS  hardware,  a brief  statement  of  their  function  provides  additional  insight 
into  the  capability  provided  by  SDVS.  Further,  the  External  Environment  Simulation 
provides  a simulation  of  avionics,  airframe,  and  environmental  conditions  which  interact 
with  the  software  being  simulated  by  either  ICS  or  SLS,  so  that  EES  is  not  DAIS-specific, 
but  can  be  utilized  with  any  software  simulation. 


i 

1 


2.5.2.7.1  Interpretive  Computer  Simulator  (ICS) 

The  purpose  of  the  ICS  is  to  provide  a functional  simulation  of  a computer  (in  this  case 
the  DAIS  Hot  Bench  Computer)  in  the  absence  of  the  actual  computer.  The  ICS  is  a 
software  module  of  the  overall  SDVS  system  and  executes  mission  software  written  for  the 
actual  computer  in  order  to  expedite  debugging,  integration  and  execution  of  these 
programs.  Multiple  computers  can  be  simulated  with  the  ICS  software.  The  individual 
computers  are  simulated  serially  by  the  ICS,  but  the  clock  is  advanced  in  a manner  to 
simulate  parallel  operation  of  multiple  processors. 

The  ICS  simulates  the  operation  of  a computer  at  the  instruction  level.  The  instruction 
set  is  simulated  in  such  a way  that  the  resulting  contents  of  registers  and  memory  is  the 
same  as  would  result  from  actual  operation  of  the  computer.  Instructions  are  simulated  one 
at  a time,  and  input/output  operations  are  carried  out  with  other  simulation  models  (e.g., 
the  EES  models)  after  each  instruction.  The  simulation  includes  operations  of  input/output, 
all  addressable  registers  and  memory.  Instruction  execution  times  are  passed  from  the  ICS  to 
the  Simulation  Control  Program  in  order  for  the  computer  execution  times  to  be 
coordinated  with  other  aspects  of  the  simulation;  control  is  returned  to  the  SCP  after  each 
instruction.  Figure  2. 5. 2. 7-1  illustrates  the  interface  of  the  ICS  with  other  modules  of  the 
SDVS  system. 

2.5.2.7.2  Statement  Level  Simulation  (SLS) 

Whereas  the  Interpretive  Computer  Simulation  simulates  computer  software  execution 
at  the  instruction  level,  the  Statement  Level  Simulation  simulates  software  execution  at  the 
JOVIAL  source  statement  level.  The  SLS  interacts  with  the  JOVIAL  compiler  to  produce 
DECsystem-10  code  corresponding  to  one  JOVIAL  statement  at  a time.  Multiple  SLSs  may 
run  concurrently  in  SDVS  in  order  to  simulate  multiprocessor  systems.  Simulated  execution 
time  is  provided  by  the  JOVIAL  compiler  based  on  statement  execution  times  provided  by 
the  programmer.  The  SLS  uses  these  times  to  provide  a rough  synchronization  between 
concurrently  running  SLSs.  An  illustration  of  the  interaction  of  SLS  with  the  modules  of 
SDVS  and  the  JOVIAL  compiler  is  provided  by  Figure  2. 5. 2. 7-2. 

2.5.2.7.3  Data  Bus  Simulator  (DBS) 

The  DAIS-oriented  simulations  described  in  this  section  allow  the  simulation  of  a 
multiprocessor  architecture  with  data  transfer  via  a multiplexed  data  bus.  The  data  bus  is 
assumed  to  interconnect  the  processor  with  sensors  through  intelligent  remote  terminals  and 
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Figure  2.5.2.7-1.  ICS  inputs  and  outputs. 


Fiflire  2.S.2.1-2.  SLS  inputs  and  outputs. 


to  conform  to  M1L-STD-155A  bus  protocol.  The  DBS  is  thus  essential  to  a simulation  of 
mission  softwurt'  interaction  witli  the  external  world  represented  by  sensors/actuators. 

The  DBS  simulation  is  set  up  by  the  user,  using  SCL,  by  providing  four  types  of 
information: 

1.  Values  of  SDVS  variables  which  control  the  attributes  of  the  data  bus  such  as 
trairsfer  rate  and  gap  time, 

2.  Values  of  SDVS  variables  which  define  the  remote  terminals  addresses  and 
subaddresses, 

3.  Values  of  variables  which  effect  the  simulation  of  data  bus  htuxlware  errors,  and 

4.  Values  of  SDVS  variables  which  cause  the  initiation  of  interrupt  services  which  are 
associatetl  with  data  bus  interrupts. 

These  vtuiable  descriptions  also  suggest  the  functions  performed  by  the  DBS.  .Additional 
insight  into  the  interface  between  DBS  and  the  SLS,  ICS,  and  EES  is  provided  by  Figures 
2.5. 2. 7-1,  2,  and  3 in  this  section. 

2.5.2.7.4  External  Environment  Simulation  (EES) 

When  the  mission  software  modules  being  simulated  are  those  which  would  normally 
require  interaction  of  the  software  with  avionics  hardware  (e.g.,  air  speed  data  or  airframe 
dynamics  parameters),  the  hardware  with  which  such  interactions  would  take  place  is 
modeled  by  the  External  Environment  Simulation.  Specifically,  EES  provides  the  simulation 
of  the  environment  as  represented  by  the  areas  of  mission  profile,  aircraft,  and  flight 
dynamics  models,  environmental  models,  and  sensor  models.  The  relationship  of  the  EES  to 
the  other  SDVS  modules  is  shown  in  Figure  2.6.2.7-3.  The  EES  receives  inputs  from  the 
mission  software  being  simulated  via  the  data  bus  or  executive  simulation,  all  of  which  are 
being  sequenced  by  the  Simulation  Control  Program.  The  EES  models  compute  the  required 
data  and  return  it  to  the  mission  software  simulation.  The  Simulation  Control  Program  may 
also  record  model  outputs  on  the  Rough  Output  Tape  as  directed  by  SCP. 

The  EES  models,  which  are  derived  firom  the  same  basic  set  as  those  described  under 
AVSIM  (Section  2.6)  can  be  called  on  either  a demand  or  periodic  basis.  The  EES  models 
are  listed  in  Table  2.6.2.7-1.  Their  function  is  to  simulate  aircraft  position  and  external 
world  state.  Models  may  be  called  on  a user-specified  periodic  basis  or  they  may  be  called  on 
a demand  basis  when  the  Data  Bus  Simulation  makes  a request  to  store  data  into  or  extract 
data  from  that  model’s  variables.  Similarly,  models  of  the  switches  available  to  the  pilot  in 
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Rfarc  2.5.2.7-3.  EES  dtta  inttrfac* 


TABLE  2.SJ.M.  EES  PERIODIC  MODELS 


r, 

i 

t 


Modal  Ntm* 

Function  oi  Modal 

Airitimt  lAFI) 

Utilitas  linear  aerodynamic  coafficiantt  to 
modal  airframa  dynamics  in  6 degrees  of 
freedom. 

Atmosphtrt  (ATMO) 

Simulates  atmospheric  conditions  such  as 
tamparatura,  pranura,  and  wind. 

Doppitr  (DOPLER) 

Simulates  dopplar  radar  measuring  ground 
speed  and  draft  angle. 

Earth  (EARTH) 

Models  rotating  oblata  spheroid  earth  to 
provide  aircraft  to  earth  data  in  flii^t. 

Ground  (GROUND) 

Inanial  Maaiuramant  Sat  (IMS) 

Models  ASN-90  IMS  by  computing  north- 
east-vertical incremental  velocities  and 
accepting  gyro-torquing  pulses. 

Propal  (PROPEL) 

Calculates  thrust  of  TF41-A-1  engine  as 
function  of  mach  number  and  altitude. 

Air  data  computar  (ADC) 

Models  free  air  temperature,  static  pressure 
and  impact  pressure  as  a function  of 
altitude. 

the  cockpit  simulator  (Section  2. 1.2.3)  are  provided  in  EES.  Switch  models  are  listed  in 
Table  2.5.2.7-2.  Interaction  of  these  models  with  SDVS  is  illustrated  by  Figure  2.5.2.7-4.  A 
status  word  indicating  the  status  of  the  keyboarri  and  a switch  position  is  entered  into 
common  for  use  by  software  simulation  programs. 

The  EES  also  provides  the  user  with  two  options  for  specifying  aircraft  position 
data:  either  from  a dynamic  model  or  from  a data  tape.  Depending  on  the  altitude  of  the 
aircraft,  either  the  GROUND  or  AIRPLANE  motlel  is  cant'd  when  the  user  chooses  the 
model  option.  When  the  data  tape  option  is  chosen,  position  data  is  input  from  a tape  whose 
name  is  specified  in  a DATA-TAPE  statement.  In  this  case,  the  user  can  input  also  the 
number  of  periodic  cycles  between  update  of  the  flight  profile  data  from  tape. 
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TABLE  2.S.2.7-2.  EES  COCKPIT  CONTROL  OEMANO  MOOELS 


MedtINaiM 


Function  of  Componont  Modriod 


Maitor  Mod*  Pinol  Switchot  (MMPSW) 

Intogrittd  Multifunction  Keyboard  (IMFKS) 

Octa  Entry  Keyboard  Swntchat  (OEKSW) 
Vertical  Situation  Display  Sveitches  IVSOSW) 
Honrontal  Situation  Display  Ssyitches  IHSDSW) 
Multipurpose  Display  Dne  Switches  (MPDIP) 
Multipurpose  Display  Two  Switches  (MPD2PI 
Multifunction  Keyboard  (MFK) 

Processor  Control  Panel  Switches  (PCPSW) 
Armement  Panel  Switches  (APSWS) 

Sensor  Control  Unit  Switches  (SCUSW) 

Flight  Control  Stick  Switches  (FCSSW) 

Left  Consols  Panel  2 Switches  (LCPES) 

Left  Console  Panel  10  Switches  (LCP0S) 


Select  one  of  15  mission  segments  (e.g.,  prellight,  takeoff, 
climb,  radar  bombing) 

Select  one  ol  7 processor  functions  (e.g.,  communication, 

sensors) 

Keyboard  entry  of  data  (0-9,  ENTER,  CLEAR). 
Horirontal/Verlical  Situation  Display  Swap,  2 spares 
Select  FLIR,  Radar,  Range  up/down,  Tiack  up/down,  chan 
Select  vsnical/multipurpose/horirontal/other  display 
Select  vertical/multipurposa/horirontal/other  display 

Select  one  of  7 processor  functions  (e.g.,  communications, 

sansors) 

“ Reconfigure''  or  "start"  processor 

Select  jettison,  fusing,  end  guns  high/low 

SeiKt  FLIR,  sonen,  laser,  radar,  etc. 

Control  trigger,  armament  release,  targat- 
waipon,  piKh/roll  trim,  etc. 

Select  flight  control  end  elKtrical  power 
functions 

Air-air  initiate  and  air  ignite  twitches 


Figure  2.S.2.7-4  SOVS/kaybeard  medal  intaraction. 
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2.5.2.8  Snapshot/Rollback 


The  Simulation  Control  Language  includes  a SNAPSHCXl'  statement  that,  when  executed 
during  the  course  of  a simulation,  results  in  saving  Uie  state  of  the  mission  software,  the 
code  executors,  the  data  bus  model,  and  the  environment  models.  A snapshot  can  be 
performed  tmseti  on  a conditional  event  (e.g.,  WHEN  A > 50  or  B < 30  THEN  PERFORM 
SNAPSHOT),  or  at  periodic  intervals  as  defined  in  the  Simulation  Control  Language. 


I 

1 

1 

i 


The  user  can  later  initiate  a rollback  via  the  SDVS  Rollback  mode  to  any  simulation 
snapshot  point  and  restart  the  simulation  from  that  point.  In  restarting  a simulation,  the 
user  can  modify  his  test  case  files  to  delete  or  add  new  conditions  to  be  evaluated, 
reinitialize  mission  software  and  environment  model  data,  and  add  or  delete  SCL  control 
blocks  (subroutines). 

2.5.2.9  Hot  Bench  Computer  Loaders  (HBCL) 

The  HBCL  performs  the  task  of  loading  J73  and  HBC  Cross  Assembler  object  files  into 
one  or  more  simulated  computers.  The  user  specifies  the  files,  and  how  they  are  to  be 
loaded,  through  the  SCL  CONFIGURE  statement  (Section  2. 5. 3. 2).  The  resulting  load  map 
is  produced  in  the  simulation  run’s  log  file.  Also,  the  user  can  request  that  the  Loader 
generate  an  ASCII  file,  readable  by  the  Hot  Bench  Computer  Bootstrap  Loader,  which 
describes  the  core  image  loaded  for  an  ICS  simulation  run. 

The  SCL  CONFIGURE  statement  allows  the  SDVS  user  to  specify  the  type  of 
simulation  (either  SLS  or  ICS)  and  the  object  files  to  lie  loaded  and  executed  on  one  or 
more  simulated  computers.  The  object  files  may  be  mission  software  procedural  (both 
executive  and  application  modules),  COMPOOL,  and/or  uncataloged  files.  For  cataloged 
procedural  files,  the  SCL  Compiler  will  automatically  configure  any  COMPOOLS  referenced 
by  that  file  which  have  not  previously  been  configured.  The  list  of  REL  files  to  be  loaded  on 
each  simulated  computer  (the  File  Directory)  will  not  contain  duplicate  files,  except  for 
library  files.  A library  file  can  be  specified  more  than  once  on  a single  computer  to  resolve 
undefined  external  references  which  exist  at  that  point  in  the  load. 

Also,  through  the  CONFIGURE  statement,  the  SDVS  user  can  optionally  specify  the 
starting  load  addresses  for  each  file’s  data  and  code  segments  for  an  ICS  load.  This  feature 
does  not  apply  for  SLS  loads. 


t. 
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2.5.3  Using  SOVS 


2.5.3.1  Modes  of  Operation 

The  varioii.s  pru^p’ums  desiTibed  in  Seetion  2.5.2  art*  invoked  by  enterinu  one  of  the 
seven  iwisie  modes  of  the  SDV'S.  These  modes  may  i)e  execuU'd  in  either  conversational  or 
l>atch  format  ilependinu  on  the  user’s  needs.  The  desm‘d  mode  is  selecuni  upon  entry  to  the 
SOVS  i>y  typing  “R  SOVS"  us  illustrat«Hi  below. 

R SOVS 

WKU'OMK  TO  SOVS  VER.3Bl760t)l  1),  YEAR,  MONTH,  OAY 
(LOGS  NAMES  L14370  ASSIGNEO  TO  THIS  SOVS  RUN) 

SOVS  IS  REAOY.  WHICH  MOOE  OK  OPERATION  IS  OESlREO’.> 

++  + HELP 

PLEASE  ENTER  NAME  OR  INITIALS  OF  ONE  OF  THE  FOLLOWING: 


FILE  GENER.VriON  (FG) 

SET  UP  & RUN  SIMULATION  (SURS) 

POST  HUN  EDIT  (PRE) 

ROLLBACK  (RB) 

OELETE  MOOE  (MANAGER  ONLY)  (OM) 

SUPERVISOR  MOOE  (MAN.VGER  ONLY)  (SM) 
LOGOFF  (LOG) 


Bastxl  on  the  user  reply,  one  of  the  modes  will  be  entert'd  by  SOVS  and  the  desiretl 
operations  can  be  performwL 

2.5.3. 1.1  File  generation  mode 

The  File  Generation  mode  provides  the  necessary  tools  and  configuration  management 
j aids  for  maintenance  of  all  files  associated  with  the  development,  test,  and  verification  of 

software.  An  extensive  cataloiting  system  is  mamtaineil  for  a number  of  diffenmt  types  of 
software  controlled  by  SOVS  includini;;  mission  software,  SOVS  test  case  files  (defining 
simulation  scenarios  and  data  collection  rcquiri'ments),  environment  and  aircraft  models, 
and  post  simulation  data  ntluction  and  analysis  programs.  Manipulation  of  files  catalogtHl  in 
' SOVS  is  providetl  for  by  a number  of  conversational  commands  (e.g..  editing,  compiling, 

printing,  etc.)  listtnl  in  Section  2. 5. 2. 3 

2. 5.3.1. 1.1  File  Structure.  Each  file  lyin'  is  catalogeil  by  SOVS  on  a version  revision 
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basis.  For  oxuinpU*.  wlu'n  llu*  usor  on-atos  a mission  softwaro  filo,  it  is  oataloneii  as  vi'i'sion  1, 
revision  0 and  stontl  in  a ’‘tiaselnu’  filo”.  As  tho  iisor  txlits  tho  filo  in  later  sessions,  he 
ereates  a numln'r  of  revisions.  Kaeh  revision  results  in  the  etlittxl  ehanges  liein^’  eatalo^teii  us  a 
unu|ue  reeonl  in  the  “differt'nee  file"  for  the  particular  file  version.  At  any  }K>int.  he  may 
wmbine  all  or  piu^t  of  the  n'visions  associatwi  with  a particular  version  and  make  a new 
version  with  the  conversational  NFA'l'-V FUSION  command.  Under  SDVS  the  user  cun 
access  any  version  ami  revision  number  for  a file  since  each  KDl'I'  session  generates  a unuiue 
entry  in  the  difference  file  for  a particular  file  version.  In  interpreting  conversational 
commands,  SDV’S  will  interrojjate  tiie  Configuration  Management  Catalogs  to  determine  if 
the  user  has  authority  to  access  the  desirwl  file  its  established  under  the  supervisor  mcnle. 

2.5.3.1.1,2  File  Types,  I'hert*  are  three  basic  file  types  maintained  by  SDVS.  mission 
software,  simulation  test  case,  and  post  run  edit.  Several  other  file  types  are  descrilu'd  by 
the  SDVS  User’s  Manual.  Fach  of  the  thn'e  basic  types  is  descrilu'd  briefly  in  the  following. 

i The  SDV'^S  catalogs  provide  configuration  control  for  the  ilevelopment,  test,  aiul 

I maintenance  of  the  mission  softwiure.  The  user  has  the  capability  to  cri'ate  and  I'tlit  JOVl.M. 

4 ciule  and  COMPtX)L  data  files.  SDVS,  in  response  users  commands,  will  automatically  link 

* COMl’OOL  data  files  to  program  files  in  the  catalogs.  The  user  is  able  to  produce  listings, 

save  newly  created  and  mxlated  files,  and  invoke  Uie  JOVl.AL  iI7d  compiler  or  the  D.\1S 
prtH-essor  assembler.  The  SDVS  will  automatically  catalog  all  revisions  made  to  a mission 
software  file,  and  catalog  object  modules  from  successful  compilations. 

The  File  Generation  mode  of  SDVS  operation  also  provides  tlte  user  Ute  capability  to 
create,  nuuiify,  and  translate  source  test  case  files  containing  Simulation  Control  lainguage 
(see  Section  2. 5.3. 2)  .staU'ments.  These  source  test  case  files  provide  the  directives,  which 
define  the  initialization  and  control  of  a simulation  run  including  sequences  of  operations, 
failure  conditions,  outputs  to  the  rough  output  tape  for  post  processing  in  tlie  Post  Run 
Fdit  Mode,  etc. 

The  user  inputs  to  build  test  case  files  are  of  two  types.  Conversational  Language  aiul 
Simulation  Control  Language.  The  user  enters  Conversational  Language  commands  to  enter 
the  appropriate  file  handling  mode  of  operation,  i.e.,  create,  t>dit,  print,  copy,  etc.  The  test 
case  files  themselves  will  contain  statements  in  the  Simulation  Control  Language  which  art', 
at  ust'r  request,  translatetl  to  an  internal  form  for  later  use  in  directing  a Simulation  run. 

The  primary  output  of  building  test  case  files  are  the  internal  test  case  files  which  lua* 
used  to  control  the  initialization  and  execution  of  simulation  runs.  In  addition,  the  user 
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r«v«Mv»‘s  mterui-tivf  outputs  ilurin^;  file  inanipulatiou.  siuh  as  suorossful  i-oiuplt>tiou  ami 
error  n\«'ss;u;es. 

The  test  ease  dm-etiveN  file  will  refereuee  inissiviu  >oftware  files  that  are  to  he  usihI  iii  th«' 
MinulatioM.  It  will  provule  direi-tives  to  jjenerate  the  rou^h  output  tape  whieh  will  1h- 
analyzed  after  the  simulation  run  is  eompU'te.  The  test  ease  direetive  souree  ami  internal 
files  are  malntalnt^l  in  th»'  Sl)\’S  file  eatalojts. 

The  File  lieneration  mode  of  SDN’S  i>peration  also  provides  the  user  with  the  eapahility 
to  ereate.  modify,  anil  translate  souree  I’ost  Kun  Kdit  direetives  files  that  will  eontain 
>tatements  m the  Data  I’roeessin^;  l.anjtuasje  whieh,  at  user  reiiuest,  are  translated  to  an 
internal  form  for  input  to  the  Post  Run  Kditor. 

I 

I The  primary  output  of  this  moile  of  operatu'ii  lu'e  the  internal  I'KK  direetives  files  that 

are  us«>il  m the  Post  Kun  K.ditor  SDN’S  iiKHie  to  perform  data  editint;  funetions  on  .1 
partieular  rou>;h  output  tat>e  ^jenerated  hy  a simulation  run.  In  addition,  the  user  will  ohtain 
mteraetive  outputs,  sueh  as  sueeessful  eompletion  and  error  messajtes.  during,'  the  file 
manipulation  and  translation  prin-ess.  The  PRK  direetives  files,  souree  and  internal,  are 
’ eatalomii  hy  SDN'S  .N  PRK  directives  file  may  Ih‘  sptvified  hy  the  user  in  a test  ease  file  to 

' he  automatically  run  at  the  end  of  a simulation  run. 

I 

2.5.3. 1.2  Set  up  and  run  simulation  mode 


I 

i 

i 


This  mode  of  operation  is  ustxl  to  submit  a simulation  run  basin!  on  a test  case  din'ctives  ; 

file  that  has  previously  bin'ii  cnnitin!  and  translated.  The  user  inputs  for  this  mode  of  ; 

operation  include; 

j 

1.  Spivification  of  either  disk  or  tape,  S 

2.  Specification  of  the  test  case  file, 

3.  Maximum  simulation  time, 

4.  Post  Run  Edit  Piximpting  commands, 

5.  Time  of  day  or  delay  time  for  executing  the  simulation  SDVS  will  automatically: 

a.  Retrieve  the  test  case  file  and  load  the  spei'ifieti  mission  softwan'  for  simulation, 

b.  Interact  with  the  machine  operator  to  mount  the  nei'essary  tapes, 

c.  Perform  initialization  commands  specified  in  the  user's  test  case, 

d.  Execute  the  desired  simulation  si'enario  and  produce  a Rough  Output  'Pape 
(ROT),  and 

e.  If  s|iecifi«l  in  the  test  case,  automatically  transfer  control  to  the  Post  Run  Edit 
mtxle  and  perform  post  run  data  analysis  and  ixliting  on  the  simulation  data. 
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2.5.3. 1.3  Post  Run  Edit  mode 

riu-  Post  Kim  Klin  miHli'  proviiies  tho  iisi'r  with  tho  ability  to  analyse  the  data  rivonltnl 
on  .1  Koii>:h  Dntpiit  I'ape  during  a simulation  run.  I'ho  Post  Kun  Kditor  aivesses  the 
user  sptvifieil  translatial  Post  Kun  Kdit  direetives  file.  'I'he  dirivtives  stH>eify  what  data  is  to 
be  seltH'iid  from  the  Kl'l'P,  what  analysis  is  to  Ih'  run  on  that  data,  what  format  is  to  lie  us»h.1 
to  dist'lay  the  analysis  results,  what  user  routines  are  to  Ih'  usihI.  and  what  deviees  are  to 
riveive  the  output  files  en'atial  by  the  Post  Kun  Kditor.  The  Post  Kun  Kditor  provides 
tabular  I'rintouts.  interaetive  displays,  and  data  plots  basixl  on  user  direetives.  .\n  important 
feature  is  the  ability  for  a user  to  write  an  analysis  routine  in  .lf>Vl.\l,  and  have  it  exeeutial 
within  the  framework  of  the  Post  Kun  Kditor. 

2.5.3. 1.4  Rollback  mode 

Phe  ndlbai'k  funetion  provides  the  user  with  the  eapability  to  ri'start  and  rerun  an  SON’S 
simulation  from  a point  during  a prt'vious  simulation  nin  as  stonxi  on  a snapshot  tape 
(Seetion  2. 5. 2. SI.  The  ust'r  may  ehan^e  the  test  ease  to  obtain  additional  output  or  alter 
existing  eonditions,  following  the  point  savixl  on  the  snapshot  tape.  The  user  does  tliis  by 
generating  a Kollbaek  test  ease  file  whieh  is  mergixl  with  the  one  useil  for  the  earlier 
simulation  by  SON’S.  I'he  user  will  input  a spix  ifieation  of  the  Kollbaek  test  ease  file  to  Ih' 
usixl  and  the  original  Test  I'ase  File.  The  outputs  of  this  mixle  of  operation  aiv  a simulation 
run  that  (if  changes  wer»'  not  made  in  the  test  ease  filel  will  exactly  match  the  prt'vious  one. 
C'hanges  may  be  made  to  provkie  further  analysis  of  a simulation  run  that  is  of  six'eial 
interest. 

2.5.3.1.5  Delete  mode 

Phis  minle  of  operation  is  only  available  to  the  SON'S  manager  and  provides  him  witli 
the  capability  to  delete  files  from  the  various  SOVS  catalogs.  This  funetion  was  made  a 
manager  level  function  to  allow  manager  level  control  over  the  dis(>usition  of  all  files. 

2.5.3.1.6  Supervisor  mode 

This  mode,  like  the  Delete  mixle,  is  available  only  to  the  SOVS  manager  for 
configuration  contn>l  purj^oses.  One  of  the  featuo's  of  the  SOVS  file  management  scheme  is 
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that  lu'forf  a user  may  any  fiU'  m Kile  t'leiieratioii  m xle,  sptvifieatums  must  liave 

hmi  created  for  that  file,  im  ludmu  the  provision  of  a list  of  us«*rs  who  are  aiithori/»'il  to 
write  (e.>; , create  ifew  versions)  on  the  file  and.  if  appixipriat* . a list  of  users  who  an-  frr-e 
only  to  read  it,  I'he  creation  of  file  specifications  must  he  performetl  from  Siiix'rvisor  mode. 
This  moile  can  In-  entered  only  hy  an  SUVS  user  lonmnl  in  on  the  special  Manaiter 
proi^’ammer  numher. 

In  SujH'rMsor  mode,  statements  in  the  t’onversational  Lannuatje  will  In*  enter»\l.  i)ne  of 
these  statements  will  allow  the  mmiaser  to  err'ate  spivifications  for  a particular  file,  and 
enter  the  initial  list  of  usi'rs  who  liavt'  authority  to  read  and  i>r  write  that  file.  Another 
statement  allows  the  manager  to  change  the  authority  of  a us<'r  from  "reaii  only”  to 
“read  write"  or  vice  vers;i.  or  add  new  users  to  Uie  list  of  authorutsi  users,  or  remov«‘  users 
from  the  list.  Bi'th  of  the.se  commaiuis  may  he  completely  sptvifunl  hy  the  user  or  he  may 
elect  to  he  partially  or  entirely  prvnnptiM.1  for  the  iuvessar>’  information. 

I'here  is  only  one  type  of  output  to  the  authoru.t\l  user  from  SuperMsor  moile.  This 
outt'Ut  consists  of  informatum  relavtsl  to  the  user  ahi>ut  the  rt'sult  of  processing  his  request. 
This  mijjht  he  a description  of  any  syntax  error  tluit  has  iH'en  detected  hy  SON’S  or  an 
indication  that  an  error  ivcurred  while  the  request  was  heint;  processixl.  or  a message 
iiulicatinit  that  the  request  was  satisfuxl.  I'he  specification  files  and  the  lists  ot  authori/.i\i 
users  are  inaccessihle  to  any  SON'S  user  whether  in  Supervisor  nuHie  or  not. 

2.5.3. 1.7  Logoff  mode 

After  exit  from  any  of  the  above  modes  of  SON’S  otieration,  the  user  will  Ix'  promptixi 
to  stdin't  a moile  of  SON’S  until  the  user  selivts  L(.)t.'.OFF.  I'l'on  sehvtmj;  SON’S  l.f't.'iOFF, 
I the  user  is  queruxl  as  to  whether  he  desires  the  transaction  log  to  Iv  pnntixl,  except  that  the 

loK  IS  always  t'rinteil  in  hatch  moile. 

2 5.3.2  SD\/S  User  Languages 

j I’he  File  Generation  mode  of  SON’S  utilues  two  spivial  lanjtxianes.  Simulation  Oontrol 

I Lanitua^e  tSt’L)  and  Oata  Processing  lainvtuatse  (OPL)  to  provide  SON  S user  a sinq'le  and 

* I effective  means  of  structuring  simulations  and  obtaining;  ivsults  of  those  simulations.  .N 

major  function  of  SON’S,  in  addition  to  providing;  a tool  for  management  of  software 
development,  is  to  implement  software  simulations.  The  limitixl  descrqhions  and  examples 
of  St'l.  and  OPL,  which  follow,  an'  important  to  an  appreciation  of  the  nature  of  simulation 
with  SON’S. 
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2.5.3.2.1  Simulation  Control  Language  (SCL) 


The  SCL  is  a projpramminjj  language.  Programs  written  in  this  language  an*  compiled  hy 
the  Scenario  Generator  (Figun*  2.5.2-1),  loadt'd  by  the  Hot  Bench  Computer  Loader  and 
interpretively  executed  by  the  Simulation  Control  I’rogram  (SCP).  The  SCL  provides  the 
mechanism  for  the  user  to  control  a simulation  by  specifying  initial  conditions,  scheduling 
events  to  occur  based  on  time  or  conditions,  and  specifying  output  to  be  generaU*d. 

The  SCL  language  syntax  is  patterned  after  the  JOVIAL  language  and  can  be  categorized 
into  (1)  non-executable  statements,  (2)  sequential  statements,  and  (3)  asynchronous 
.statements.  The  non-executable  statements  are  used  to  convey  control  information  to  the 
simulation  system  such  as: 

1.  The  mission  software  to  be  simulated, 

2.  The  flight  profile  tape  to  be  used, 

3.  The  Post  Run  Edit  program  to  be  executed  after  the  simulation, 

4.  The  variables  to  be  traced, 

5.  The  type  of  computer  simulation  (ICS  or  SLS),  and 

6.  The  type  of  rollback  (and  time). 

Certain  sequentially  executed  statements  provide  many  of  the  capabilities  of 
conventional  programming  languages  such  as  FORTRAN,  PL-1,  and  JOVIAL.  Other 
.sequential  statements  direct  the  Simulation  Control  Program  to  perform  a simulation-related 
function.  These  statements  are  used  to: 

1.  Assign  values  to  variables, 

2.  Transfer  control  to  other  statements, 

3.  Evaluate  a logical  expression  and  execuU*  one  of  two  statements  depending  on  the 
value  of  the  expression, 

4.  Activate  simulated  computers, 

5.  Collect  data, 

6.  Turn  traces  on  and  off,  and 

7.  Terminate  the  simulation. 

A.synchronous  statements  are  not  executed  sequentially;  they  are  executed  asynchronously 
as  the  result  of  a user-specified  condition  becoming  true.  In  a sense,  the  true  state  of  the 
condition  behaves  as  a software  interrupt  that  triggers  the  execution  of  the  statement. 


281 


1m  uMtu'ipaUoM  of  ail  fxampU'  of  tin*  use  of  SlM„  a liru'f  I'xplaiuiUon  of  thf  Itasu- 
stnu-luiv  of  an  SC'l,  siimilalion  aiul  a i iirsory  liosi-nption  of  llu'  Sl’l-  i-onnuaiuls  is  in  onlfr 
A siMuilatioM  in  SC'l,  is  I'onfiniiix'd  oitlu’i'  as  an  "initial  lost  oaso,  in  wliu'li  tiu'  >S(  I, 
stati'iui’nls  am  struotimal  into  llimi*  ilistiiu't  si'i'lions  (nai’li  of  wliioli  is  optional),  or  as  a 
"rollliai-k  tost  oaso"  with  two  sivtions.  Tlu'  ilisonssion  horn  will  Im>  linutoil  to  ttio  "initial  tost 
oaso."  'I'lioso  sootions  whioh  appoar  in  tho  initial  tost  oaso  must  do  so  in  this  ordor: 

1,  CoidViiro  sootion. 

2.  Hlook  soot  ion.  and 

;i,  rimo  /.oro  sootion. 

I'ho  oonfir;uro  sootion  oontains  a dosoription  of  tho  Mission  Softwari'  and  S1)\'S  filos 
that  am  to  ho  hiadi'd  for  tho  simulation.  Tho  hlook  sootion  oontains  tho  dofinition  ot  all 
hlooks  that  aro  to  ho  rofonmood.  Tho  timo  /.oro  sootion  oontains  statomonts  that  uutiali/.o 
variahlos.  provido  simulation  timing  information  or  oontrol  data  rooordmn  and  analysis. 

2. 5. 3.2.1. 1 Configure  Section.  I'ho  oonfinuro  sootion  oonsisls  of  ono  or  moro 
CO.NFKIUHK  or  INC'l-l'DK  statomonts.  It  allows  tho  u.sor  to  siiooif>  tho  typo  of  smmlalion 
toithor  S1,S  or  K'S)  and  tho  MSW  moilulos  to  ho  loailoil  and  oxocutod.  Tho  simulation  oan  ho 
oonfi>jumd  m ono  of  two  modos  of  oporation.  oifhor  "standalono"  or  “full  blown."  In  tho 
stnndalono  modo.  tho  usor  may  spooify  MSW  applioation  modulos  to  ho  oxooutixl  on  oithor 
ono  SLS  or  ono  K'S  oodo  prooossor.  In  tho  full-hlown  modo,  MSW  Exooutivo  .Applioation 
miHlulos  may  ho  spooifiod  for  a maximum  of  Ih  Hot  Bonoh  C'omputors  (all  Sl.S’s  or  K'S’*). 
Tho  samo  MSW  modulo  oan  ho  stiooifiod  for  loadinn  onto  moro  than  ono  ooiio  prooossor.  For 
oxamplo.  tho  oommand  C'ONFK'iUUK  ASSltlN  1 MSW'-l/l/.'l  sjHvifios  a standalono  modo 
statomont  lovol  simulation  of  an  MSW  modulo  1/1/3  (filo/vorsion/rovision).  I ho  statomont 

('ONKK'.URE  PROCESSOR/ICS 

siuvifios  tho  Intorprotivo  t’omputor  Simulator.  Assitcnmont  of  MSW'  modulos  to  a prooossor 
is  aooompli.sluxl  hy  a ('ONFKIURE  ASSIGN  statomont. 

2.5.3.2.1.2  Block  Section.  Tho  hlook  sootion  is  made  up  of  oithor  hlook  swtion 
statomonts  or  INCIAIDE  statomonts.  Thoro  aro  five  kinds  of  hlooks.  oaoh  hounded  hy 
BEGIN  and  END  delimiters: 


1.  Control  hlook, 

'2.  Repetition  hlook. 


3.  KFS  block, 

4.  RO  T block,  und 

5.  Maneuver  l)lock. 


Contxol  block  stateiuenUs  may  be  divulp<i  into  four  jp-oups: 

1.  Ibicondilioiial  stab'inents, 

2.  Conditional  statements, 

3.  IN  statenumt,  and 

4.  I’KUFORM  statement. 


The  unconditional  statements  are  SETVALVE,  SNAPSHOT,  TERMINATE  and  a 
limitwl  PERFORM  statement.  The  conditional  statements  are  WHEN,  WHENEVER, 
WHILE,  IF  and  a limited  IF  used  only  in  a repetition  control  block  or  EFS  block.  The 
WHEN  sUtement  contains  a condition  and  a substatement.  The  first  time  the  condition 
bwome  true,  Uu*  substatement  is  executeil.  The  WHENEVER  statement  also  contains  a 
condition  and  a substatement.  Everytime  the  condition  becomes  true,  the  substatement  is 
executetl.  The  WHILE  staUmient  contains  a condition,  a repetition  frequency  and  the  name 
of  an  SCL  procetiurt*.  Until  the  condition  becomes  false,  the  SCL  procedure  is  performed 
repent»*dly  at  that  specifiwl  raU'.  The  PERFORM  statement  schedules  execution  of  a 
specifiwl  block  either  once,  for  the  cummt  time,  or  repeatedly,  starting  with  the  current 
time  until  « specifitxl  time. 

A repetition  block  is  a control  block  that  is  restricted  to  certain  kinds  of  statements.  For 
example,  it  must  be  used  instead  of  a control  block  when  executing  a complex  PERFORM 
statement  or  a PERFORM  statement  that  is  t^ie  dependent  statement  of  a WHENEVER  or 
WHILE  statement.  The  EFS  block  contains  exactly  tlie  same  kinds  of  statements  as 
repetition  control  block,  but  EFS  blocks  an'  meaningful  only  in  standalone  mode. 

A ROT  block  consists  of  a list  of  one  or  more  variable  names  separated  by  commas.  For 
example. 


BLOCK  ROT-EXAMPLE 
BEGIN 
S:I01, 102,103 
END; 

defines  variables  101, 102, 103  whose  values  are  to  be  recordetl  on  the  ROT. 
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'I’hf  maneuver  hloek  consists  of  a sequence  of  one  or  more  assignments  to  External 
Environment  Simulator  (EES)  variables.  For  example, 

BLOCK  MAN-EXAMPLE 
BEGIN 
E:ALA1'=0., 

E:ALONG=0. 

END; 

defines  initial  values  for  two  EES  variables,  ALAT  and  ALONG. 

2. 5.3.2. 1.3  Time-Zero  Section.  Thn*e  types  of  statements  may  appear  in  the  time-zero 
section; 

1.  Initialization  statements, 

2.  Control  statements,  and 

3.  Include  sUitements. 

The  INITIALIZE  sUtements  include  INITIALIZE,  ACTIVATE,  TRACE-LIST, 
DATA-TAPE  and  POST  RUN  EDIT.  The  INITIALIZE  statement  is  ustnl  to  assign  values  to 
SDVS,  mission  software  and  F^ES  variables  at  the  beginning  of  a simulation.  'I'he  ACTIVATE 
statement  specifies  start  times  for  the  various  computers  defined  in  a simulation.  The 
TRACE-LIST  spwifies  those  SDVS,  MSW  and  EES  viuiables  whose  values  an*  to  la*  tracwl 
during  a simulation.  The  DAI'A-TAPE  statement  gives  the  name  of  a tape  from  which  EES 
data  is  to  be  read  during  simulation.  The  POST  RUN  EDIT  staU*ment  gives  the  name  of  a 
file  of  post  run  t*dit  directives  that  are  to  be  processed  by  the  Post  Run  Editor  at  the 
completion  of  the  simulation  run. 

To  illustrate  the  use  of  the  SCL  in  testing  mission  software,  consider  the  development  of 
a new  navigation  algorithm,  NAV,  that  has  been  created  and  compiled  in  tlie  SDVS  mission 
software  file  catalogs.  The  user  is  interested  in  generating  a flight  profile  such  that  the  SDVS 
avionic  and  sen.sor  models  will  gen»*rate  realistic  navigation  sensor  data  for  input  to  the  NAV 
routine. 

Figure  2. 5. 3. 2-1  is  a pictorial  representation  of  the  following  flight  scenario: 

1.  Takeoff  is  at  latitude  35".  Utngilude  117"  with  a thrust  command  of  1200  lu'unds. 

2.  When  the  X velocity  > 170  fps,  pitch  the  aircraft  at  2'’/stvond. 
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3.  When  the  pilch  angle  20"’,  maintain  that  pitch. 

•1.  When  altitude  exceeds  10,000  teet,  level  the  aircraft  hy  setting  a negative  pitch  rate. 

f).  When  the  pitch  angle  is  less  than  zero,  terminate  the  simulation. 

[Ising  the  SDV’S  SCL,  the  user  huilds  a test  case  file  to  specify: 

1 . The  flight  profile. 

2.  Data  tt)  he  recorded  for  post  processing. 

3.  Sensor  daUv  to  he  usetl  hy  the  NA\'  routine. 

Figure  2. 5. 3. 2-2  is  an  SCL  program  for  Uiis  example.  The  reader  should  note  the 
following  points  in  this  sample  program: 

1.  The  CONFIGURE  statement  specifies  the  STANDALONE  mode  which  allows  a user 
to  interface  directly  with  environment  model  data  via  an  EFS  (Executive  Functional 
Simulation)  block  instead  of  using  the  real  DAIS  executive  softwan*.  It  also  sptvifies 
the  SDVS  simulator  (the  SLS)  and  the  files  to  be  loaded  (version  1 revision  0 of 
NAV). 

2.  The  EFS  Control  Block  (EFS-NAV-INPUT)  defines  the  assignment  of  environment 
mode  sensor  data  (denoted  hy  the  prefix  E:)  to  variables  in  the  (rrogram,  NAV. 
These  assignment  statements  will  be  executed  periodically  at  32  timt's  per  stvond 
prior  to  executing  the  NAV  routine  as  defined  hy  the  statement. 

PERFORM  EFS-NAV-INPUT  EVERY  .03125  UNTIL  1000; 

3.  The  INCLUDE  statement  allows  the  user  to  copy  in  other  test  case  files  to  be 
included  as  part  of  the  test  case. 

•1.  The  ROT-SIM-DATA  block  defines  model  and  mi.ssion  software  position  data  that  is 
to  be  recorded  once  a second  as  defined  by  the  statement, 

PERFORM  ROT  SIM-DATA  EVERY  1 UNTIL  1000; 

5.  The  CON-INIT  block  defines  all  the  initial  conditions  at  ground  zero.  These 
assignments  are  executed  by  the  statement, 

PERFORM  CON-INIT; 


6.  The  statements  defining  the  mission  profile  correspond  to  the  flight  profile 
illustrated  in  Figure  2. 5. 3. 2-1. 
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-FlU  DATA  COLLECTION  -COIFlGURE  TME  SntUUTIO*  ■■  THE  STANOAIOIE  MODE  LOAOMG 

THIS  FILE  DEFINES  DATA  TO  EE  COLLECTED  EVERT  SECOND"  VERSIW  I HEVHIOR  • Of  lAV" 


Figure  2.5.3.2-2.  Sample  SDVS  SCL  program. 


2.5.3.2.2  Data  Processing  Language  (DPL) 


An  SDVS  simulation  generates  a volume  of  data  collected  at  numerous  points  in  a 
simulation.  With  the  SCL,  the  user  can  specify  both  conditional  and  unconditional  events 
that  result  in  the  output  data  to  a Rough  Output  Tape.  This  tape  contains  all  the  simulator 
trace  outputs,  a load  map  of  the  mission  software  for  each  DAIS  processor,  run  time  error 
and  warning  messages  from  the  various  simulators,  data  from  the  environment  models  and 
mission  software  defined  by  the  user,  etc.,  as  they  occur  in  simulated  time.  Figure  2.5.3.2-2 
illustrates  the  use  of  a Rough  Output  Tape  (ROT)  block  defining  the  variables  to  be 
recorded  every  second  during  a simulation.  From  the  vast  volume  of  data,  the  user  must  be 
able  to  sort  out  and  display  the  information  in  a meaningful  format. 

The  SDVS  Data  Processing  Language  has  been  designed  to  provide  the  SDVS  user  with 
an  easy-to-use,  flexible  tool  to  select  for  analysis,  printout,  or  plotting  the  specific 
parameter  data  he  desires.  In  selecting  data  to  be  output,  the  user  does  not  have  to  worry 
about  conversion  of  mission  software  or  environment  model  data  from  binary  to  the  correct 
output  format;  this  is  all  handled  automatically  by  SDVS.  To  determine  the  correct  formats, 
SDVS  reads  the  symbol  tables  generated  for  mission  software  and  environment  model 
programs  by  the  JOVIAL  and  FORTRAN  compilers,  and  extracts  the  necessary 
information.  This  SDVS  tool  removes  much  of  the  drudgery  sometimes  associated  with  data 
analysis.  The  DPL  provides  the  following  user  oriented  functions: 

1.  Generation  and  editing  of  data  files  containing  user  defined  variables  from  the  ROT. 

2.  A PRINT  capability  to  output  generated  data  files  to  the  printer. 

3.  A DISPLAY  capability  to  output  information  to  the  user’s  interactive  terminal. 

4.  A statistical  package  to  compute  statistical  information  of  simulation  data. 

5.  Automatic  generation  of  plots  based  on  collected  simulation  data. 

6.  Execution  of  user  supplied  analysis  routines  using  a simulation  ROT. 

The  use  of  DPL  is  illustrated  by  the  DPL  program  of  Figure  2.5.3.2-3  that  can  lie  used 
to  process  data  collected  in  the  SCL  example  shown  in  Figure  2.5.3.2-2.  This  DPL  program 
is  used  to  print  out  the  environmental  model  and  mission  soft  wart'  N AV  data.  This  data  will 
be  printed  on  the  line  printer,  and  will  be  analyzed  by  a user  routine,  error  analysis,  to 
determine  the  mission  software  error.  This  error  is  then  plotted  as  a function  of  time. 

The  reader  should  note  the  following  points  from  this  sample  program: 

1.  The  CONFIGURE  statement  specifies  the  user  routine  to  be  executed,  and  its 
language  (JOVIAL). 


r 


EXAMPLE  OF  SOVS  POST  RUN  PROCESSING 


"THIS  POST  RUN-EOIT  PROGRAM  IS  USED  TO  PRINT  OUT  THE" 
"ENVIRONMENTAL  MODEL  AND  MISSION  SOFTWARE  NAV  DATA  FROM" 
"A  SIMULATION  RUN.  THIS  DATA  WILL  BE  PRINTED  ON  THE  LINE" 
"PRINTER.  AND  WILL  BE  ANALYZED  BY  A USER  ROUTINE,  ERROR" 
“ANALYSIS.  TO  DETERMINE  THE  MISSION  SOFTWARE  ERROR.  THIS" 
“ERROR  IS  THEN  PLOTTED  AS  A FUNCTION  OF  TIME" 

“SPECIFY  THE  USER  ERROR-ANALYSIS  ROUTINE" 

CONFIGURE  USER-ROUTINE  JOVIAL  ERROR-ANALYSIS/I/O: 

“GENERATE  THE  DATA  FILE,  NAV-DATA.  CONTAINING" 

"THE  PARAMETERS  IN  ROT  BLOCK,  ROT-SIM-OATA," 

GENERATE  NAV-DATA  ROT-SIM-DATA: 

"DEFINE  THE  DATA  FILE  CONTAINING  THE  OUTPUT  OF  THE  USER" 
“ROUTINE.  THIS  OUTPUT  IS  THE  NAVIGATION  ERROR  FOR  LATITUDE." 
“LONGITUDE,  ALTITUDE,  AND  THE  SIMULATION  TIME.  TIME" 

FORMAT  NAV-ACCURACY 
BEGIN 

FLOATING;  LAT-ERR. 

FLOATING;  LOW-ERR, 

FLOATING;  ALT-ERR. 

FLOATING;  TIME 
END; 

“PRINT  OUT  ALL  THE  MSW  AND  EES  NAV  DATA" 

PRINT  NAV-DATA; 

“EXECUTE  THE  USER  RDUTINE,  ERROR-ANALYSIS.  WHICH  COMPUTES" 
“THE  NAVIGATION  ERROR" 

“INPUT  FILE;  NAV-DATA" 

“OUTPUT  FILE;  NAV-ACCURACY" 

EXECUTE  ERROR-ANALYSIS 

NAV-OATA;NAV-ACCURACY; 

"PLOT  THE  COMPUTED  NAVIGATION  ERRORS  AS  A FUNCTION  OF  TIME" 

PLOT  NAV-ACCURACY  SIM-TIME.  LAT-ERR(RAO-OEGI 

TITLE-'LATITUOE  ERROR  VS  TIME' 
XLAeLE>'TIME(SEC)' 

YLABLE-'LATITUOE  ERROR  IDEGI'; 

PLOT  NAV-ACCURACY  SIM-TIME.  LOW-ERR(RAaOEO) 

TITLE-'LONGITUOE  ERROR  VS.  TIME' 
XLABLE-'TIMEISEO' 

YLABLE-'LONGITUOE  ERROR  (OEOI'; 


2.  The  t'lKNERATK  statement  is  used  to  create  a data  file,  NAV'-DATA,  which  includes 
all  the  data  on  the  ROT  block.  ROT-SIM-DATA. 

3.  The  FORMAT  statement  is  used  to  define  the  format  of  the  data  file 
(N'AV- ACCURACY)  which  is  computed  by  the  user’s  routine. 

4.  The  PRINT  statement  will  automatically  print  out  all  the  data  contained  in  the  data 
file,  NAV-DATA.  The  output  is  in  a tabular  format  and  is  time  tagged. 

5.  The  PLOT  commands  shown  allow  the  user  to  specify  the  plot  title,  the  axis  titles, 
and  any  desired  data  conversions.  4'he  user  could  also  specify  the  X and  Y axis 
lengths,  the  minimum  and  maximum  X and  Y values  allowed,  and  any  biases  to  be 
addtHl  or  subtracted  from  variables  to  be  plotted. 

SECTION  2.5  BIBLIOGRAPHY 

TRW  Defense  and  Space  Systems  Group,  "The  Software  Design  and  Verification  System 
(SDVS),"  Final  Report  for  Period  17  June  1974  to  30  June  1976,  Contract 
F33615-74-C-1159. 

TRW  Systems  Group,  "Software  Design  and  Verification  System,  Phase  HI,”  User's  Manual, 
11  June  1976. 

TRW  Systems  Group,  “Software  Design  and  Verification  System  (SDVS)  Requirements 
Document,”  15  August  1975,  6404. D-91. 

2.6  AVSIM 

AVSIM  is  a simulation  facility  that  effects  avionics  system  evaluation,  validation,  and 
integration  by  dynamic  digital  simulation  of  the  airframe,  flight  controls,  and  avionics 
equipment  of  a generic  high-performance  tactical  fighter.  The  objectives  of  this  facility 
currently  are  to: 

1.  Test  and  validate  operational  flight  programs  under  realistic  flight  conditions, 

2.  Effect  digital  avionics  system  integration, 

3.  identify  hardware/software  problems  in  prototype  avionics  systems,  and  to 

4.  Recreate  flight  problem  areas  through  dynamic  simulation. 

AVSIM  is  capable  of  simulating  the  navigation,  penetration,  and  weapon  delivery  phases 
of  an  attack  fighter  mission  both  individually  and  compositely.  The  AVSIM  user  configures 
his  aircraft,  sensor  complement,  environmental  characteristics,  and  target  characteristics  by 
linking  individual  simulation  models  into  an  overall  simulator  structure.  The  AVSIM  simu- 
lator currently  has  real-time,  non-real-time,  man-in-the-loop,  and  self-contained  modes 


of  operatiou.  The  user  hiis  Uu*  option  of  using  resident  (K-IG)  software  developeti  by  ] 

(lenera!  nyuannos  of  Ft.  Worth,  using  resident  (A7)  software  obtained  from  the  Navy,  or  of  | 

developing  his  own  by  utilization  of  resident  creation  routines.  In  the  example  of  the 

resident  software,  the  airframe  is  configured  by  selecting  either  an  F-16  or  A7  aiixTaft  i 

mcxiel,  an  appropriate  flight  control  system  dependent  on  desirtnl  complexity,  and  selecting 

self-contaimxl  (synthetic  mission  generator/simulated  pilot),  pre-recon.led,  or  real-time  1 

i 

cockpit  inputs.  The  sensor  complement  presently  available  includes  the  radar  altimeter,  the  j 

attack  radar,  and  (may  be  extended  to  include)  electro-optical  sensors.  Flight  environment  is 

incorporate<l  by  utilization  of  models  that  provide  simulated  air  data  inputs,  accelerometer 

luul  gyro  outputs,  representative  weather  effects,  atmospheric  perturlxitions,  inertial 

outputs,  and  magnetic  heading.  Auxiliary  software  integral  to  the  total  simulation  includes 

an  inertial  reference,  geometry  effects,  and  the  ability  to  introduce  noise  at  various  points. 

.AVSIM  is  hosted  by  the  DEC-10  facility  at  AFAL  and  is  linked  to  i>eripherals  such  as  the 
cockpit  and  display  generator  by  means  of  DMA  bus  to  satellite  PDP-lls.  .AVSIM  software 
consists  of  control  modules  and  application  models.  The  control  softwan*  provides  file 
manipulation,  sets  up  the  simulation  configuration,  provides  initialization,  implements 
man-machine  interface,  and  controls  overall  execution  sequence.  The  application  models 
provide  aforementioned  sensor  data,  external  physical  conditions,  etc.  Also  contained 
within  the  software  art'  data  acquisition  and  analysis  modules  that  accumulate  and  edit  data 
for  validation  analysis. 

AVSIM  programs  are  coded  largely  in  ANSI-FORTRAN  in  an  attempt  to  make  the 
software  flexible,  modular,  and  transferable.  DEC  system  FORTR.AN-10  features,  as  well  us 
DEC-10  assembly  language,  are  also  used  to  a lesser  degrt*e. 

The  software  module  structure  for  AVSIM  is  shown  in  Figure  2.6-1.  The  software  is 
organized  to  fwform  the  two  primary  functions  of  set-up  and  axecution.  Subfunctions 
within  program  set-up  include  the  use  of  “ENTRY. BLD"  in  the  creation  of  new  applications 
models  and  the  ust«  of  "PRESCENARIO”  to  establish  a new  simulation  configuration  by 
creating  a new  “EXECUTIVE"  where  application  model  complement,  sequence,  and 
sequence  rate  are  specified.  Actual  run-time  initialization  and  parameter  modification  is 
achievetl  in  “SCENARIO”.  These  are  discussed  in  greater  detail  in  the  following  paragraphs. 

A distinction  is  introduced  into  the  discussion  at  this  point  to  differentiate  between  the 
executive  or  control  software  and  the  applications  model  software. 

2.6.1  Executive  (Control)  Module  Software 

The  executive  or  control  modules  provide  the  supervisory  software  necessary  to  create. 
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s«‘t  up.  and  oMvulf  the  applK-atu'ns  si>ft\V!ir»‘.  I'hoso  inodulos  provide  file  nianipulation  and 
iMiUrol.  seltviion  of  the  options  to  he  run.  initiali.'.ation.  operator  input  iniitinn.  diannostie 
information,  simulation  nu>niti>rin>;.  exivutum  sixpienee.  aiul  exeeutum  eontrol. 

I'f  piutieular  interr-st  to  the  user  who  is  ereatin*;  a new  simulation  eonfinuration  are  the 
routines  'KNIKY  HI  D"  atul  ' I’UKSl’KN.VKH.)".  .\s  desiriluxl  below  these  provide 
eapahihty  to  strueture  the  entry  point  featurv'  in  new  appheations  models  and  to  eonfiuure  a 
modi'l  set  by  ^eneratin>;  a new  "KXKl'".  respivtively . The  two  modules  of  pnneiple  inteix'st 
to  the  user  at  run-time  art'  the  “IMKK.C' TOK"  aiul  the  "St.'F.N.-XK K)".  These  provide 
man-maehine  inti'rfaee  during  program  exeeutum  and  set-up.  rr'S[H'etively.  These  aiul  other 
exeeuliveand  support  software  aix'  deseriluxl  in  the  folh>winn  seetions. 

2.6. 1.1  Multiple  Entry  Points  and  Adding  New  Applications  Models 

Kaeh  model  makes  use  of  the  FOK  TR.-XN-IO  feature  to  link  into  a subroutine  at  a 
pnxleterminixl  position  in  the  subroutine  souree  einle.  Tlu'se  entry  [mints  are  aililre.sstxi  by 
the  name  of  the  a['prvi['riale  subroutine  to  wtiieli  either  '•IN".  "TT'’.  or  "F.X”  have  Iven 
apt'eiuhxl  These  rv'[’r»'sr'nt  soune  eiuie  nuHlules  within  the  last  sutnoutme.  whu  h [irovule 
for  "initialisation"  (i.e..  default  spivifieationl  "teletype"  (i.e..  operator  u[Hlate  of  the 
default  values  if  desinull.  and  "extvute"  (i.e..  .settin>;  the  .letual  run  parameters  to  either  the 
speeifuHl  default  value  or  to  the  u[HlattHi  value).  For  i'xam()le.  a link  to  FTSIN  would  enter 
subroutine  Ft'S  at  an  a('propriate  plaee  to  aeeess  the  I'resptx'ified  default  [lariuueter  list.  .-X 
subsixiuent  link  to  Ft'SF.X  would  set  the  run  [naameter  to  the  aeeessixl  ilefault  value.  These 
entry  tnunts  are  ereattxl  at  the  same  time  a new  applieation  mcnlel  is  ert'attxl  throu^th  the  use 
of  KN  TKY  .Bl.O  as  deserihtnl  in  the  Computer  Trvi(jrammer’s  Manual. 

.-Xililit tonally,  where  a new  appheations  model  is  eix'ated.  subnuHlules  INC'.-Xl.L.  INF.X. 
F.X.  NU')I')Kl.S.  and  INPl’M  nuust  Im  revisixl.  'The.se  modules  essentially  exereise  the  model 
st'tfs)  throunh  the  entry  point  linkajtes  di.seusseil  above.  For  example.  INC.-XLl.  activates  the 
imtialisatum  "IN"  proitrams  for  the  model  set  sequentially  Thus,  calls  to  the  new  model 
must  be  include!  for  each  of  these  subprograms.  In  some  instances  it  is  [xissible  to  disturb 
execution  or  initialization  lojtic  if  the  call  is  impro|.Jt*rly  ['lacel  with  the  .source  coile. 

2.6.1. 2 PRESCENARIO 

PRKSCEN.-XRIO  is  a simple  routine  use!  to  confi»tur»‘  a simulation  by  constructmn  new. 
or  motlifying  existing,  EXKC  subixnitines  (i.e..  create  or  mixlify  the  KXTKRN.-Xl.  statement 
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lilt'  uuult'l  soil.  Hy  tlio  ust'  iif  st'von  i-oinmaiuis  wliu-h  t'aii  bo  oiUort\l  ai  aii\'  roiiuito 
tormiiial,  tlio  usor  oaii: 
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1.  I'l'iifijiiiro  now  siimilalu'iis  (HOW  KXKC'K 
2 Kxtimmo  oxisUii^;  ooiifi»;iiratu>ns. 

IVloto  oonfi(;:iiratUMis  no  U>n>:t'r  noiHloil,  aiui 
■1.  Sian  a sinuilalion  usint;  any  tmo  iM'  iho  oxisiing  oonl'ijixiraiions. 

I'ho  ooniniaiuls  anil  liioir  funolitnis  aro  briofly: 

1.  I'HKA  I F.  oroaloi  a now  oxtvulivo  wiili  iho  nanio  KXKC'n.FOK. 

2.  niKKC''ri>RY  li.'iis  any  all  oxoouln os  and  iJioii  slaiiis, 

3.  KXFl'l'TK  — oompilos,  loads,  and  oxoonlos  sinuilalion  wilh  iho  now  KXKl'.  Tho 
namo  of  iho  KXKt'  is  sptx'ifunl  in  ihe  ar^i^imont  lisl. 

4.  HKl.r  — lisl  all  oomniands  availablo  and  ihoir  synlax. 

fi,  KILL  — oxils  rRKSCKN.\K10.  slort's  all  sysloni  information.  Hoos  not  oxooiito 
sinuilalion. 

tv  Rl’BOlT  — dolotos  any  all  oxo<.'iitivos  s^Hvifi^\^  as  arvnmonts. 

7.  TYPK  — tyiH's  out  all  inodols  and  tlioir  framo  ratos  for  any  all  oxtvulivos. 

I'ho  l’ro(!raininor’s  Manual  should  Ix'  ixuisulltxl  rt'nanlinn  ooininand  mnomoiuo  and 
ar)rumont(s). 

PRKSC'KN.\R10  IS  ontorod  witli  the  ooininand  ‘ Rl'N  PRKSl'N."  .\ftor  systoin  status 
flajis,  tho  systoin  rosponst'  is  rt'lurnod.  Tho  usor  then  soloots  tJio 

ooininand  appropriato  to  his  objootivo  and  ontors  it.  Tho  logio  in  pr»‘s».'onario  is  vory  siinplo 
and  oonsists  of: 


«•*•*  begin 

* GKI'  COMM.\ND  FROM  I’SER 

* DETERMINE  WHICH  tXIMMAND  W.\S  GIVEN 

• CALL  THE  PROPER  COMMAND  ROIHINE 

• IF  NOT  A KILL.  GO  TO  BEGIN 
RETURN 


The  General  Dynamics  software  documentation  indicates  that  PRESCEN.-VRIO  possesses 
a tutor  mtxle  selectable  by  the  user  at  set-up  time.  However.  RTI  review  of  available  source 
coile  did  not  immediaU'ly  evidence  this  capability. 


I 
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2.6.1.3  MAIN 


'Phis  moiluU'  liiis  two  priimiry  functions.  Tlu'  first  is  Ihc  cstalilishmcnl  of  proKrani  iluUi 
trafficking  liy  means  of  extensive  common  block  definition.  Tlie  second  is  tlie  call  to 
‘‘St'KNAUlO"  or  "IIIH KCTOH"  modules.  \ li's.ser  function  performed  by  "MAIN"  is  the 
nut  lali/.ation  of  WO  fiU's. 

2.6.1.4  SCENARIO 

Tlie  St’KN.MtIO  provides  the  non  real-limi'  interface  for  man-machine  communication 
durmn  llu'  mitiali/.ation  slaije  of  a simulator  run.  'rhe  operator  utili/.es  the  SCKNAHIO 
model  to  loail.  initialize,  and  prepare  liie  simulator  for  operation.  St’KNAHlO  enables  the 
operator  to  select  a St'KN  Alt  lO  .sen.sor  subsystem  confi).'.uralion  from  the  AVSIM  lil>rar>’ 
based  on  a pri'ilelermined  confinuration  (m  the  KXKC  module).  The  operator  has  the  option 
of  usiuK  stored  (default)  parameters  or  of  inputting  a parameter  set  of  his  own.  Warne  scale 
parameler/model  changes  are  uenerally  handled  other  than  at  set-up  by  (iroisram 
modification.  SCKN.MtlO  makes  extensive  use  of  the  multiple  entry  feature  of  the  OKI' 
FOirnWAN- 1 0 (.sec  pn'C(><lin>;  section)  on  adding  new  applications  models  for  detail). 

SCKN.VHIO  also  provides  the  operator  with  the  ability  to  double  check  anil  verify  his 
input.  Comments  an'  provided  for  many  anticipated  operator  mistakes  as  well  as  for 
assistance  in  selling  up  ihe  simulator  run  and  developinn  the  SCKNAllIO.  If  a Kiven  oiition 
is  si'li'cti'd,  information  defining  those  models  which  are  rciiuired  to  implement  that  option 
is  provided  to  Ihe  o|)eralor  by  means  of  an  optional  tutor  mode. 

The  simulator  operator  can  expect  to  be  required  to  advise  SCKNAKIO  of  Ihe  followmn 
input  options: 

1 . Monitor  Con.sole  ()|>eralor  Mode  (Tutor  or  Sel-Wp), 

2.  Airframe  Mode  (Self-ContainiHl  or  Man-ln-Woop), 

.'1.  Subsy.stem  Information, 

-1.  Sensor  Options, 

Hardware, 

<>.  Tarnet  Options, 

7.  Weather  Options, 

8.  I’arameter  Options,  or 

5).  Perform  Housekeeping  Functiens. 
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Output  from  tiu'  SCKNAKIC)  noos  to  tin-  (liroftor,  sonsor  nu»ilt*ls,  subsystem  moib'ls, 
anil  1 O sub  program  data  initialization  file.  l)lKK(”rt)R  tallies  whieh  provide  for  proper 
exeeution  of  the  loaileil  models  are  set  up  from  SCKNARIO  output.  The  DlRKt'TOR  then 
interfaces  with  SlMSl'B  and  CALl’M  in  order  to  be  synehronized  with  the  DKC’-IO  real  lime 
clock  or  the  D.AIS  flinht  proce.ssor. 

2.6.1.5  EXEC 


rile  priman,'  function  of  this  module  is  to  set  up  the  (real  time)  model  suite.  This  is 
accomplisluHl  by  defininn  those  elements  desin'd  in  an  External  statement.  Generally,  the 
nuHlels  are  selected  from  the  AVSIM  library  (currently  F-IG  or  A7  representations)  but  as 
staled  (ireviously  may  be  user  in))ut.  This  module  also  initializes  confifUiration  inmuneters. 

2.6.1.6  DIRECTOR/CALIPER 

The  DlREl'  TOR  is  the  overall  simulation  monitor  and  jirovides  the  interface  between 
St'KN.ARlO  (i.e.,  proi^am  set-up)  and  the  DEC-IO  Real-Time  ()[)eralinj;  System  (i.e.. 
jirofjram  execution).  Monitoring  tasks  include  scheduling  Uie  execution  of  sensors, 
subsystem  models,  I/O  interfaces,  data  aciiuisilion,  anil  analysis  models.  I'lirouuh 
coordination  with  St’ENARlO,  task  and  priority  tables  are  constructed  that  (irovidc  for  the 
simulator  to  execute  the  proper  models  in  the  (iroper  seiiuence.  The  user  communicates 
with  the  DlREG'l’OR  to  provide  control.  This  includes  initialization,  hold,  or  reset,  etc. 
DIR  EG  TOR  allows  the  u.ser  to  siiecify  the  followintJ  simulation  parameters; 

1 . Sense  switch  to  halt  the  simulator, 

2.  Sen.se  switch  to  allow  real-time  analysis, 

d.  Run  time  limit, 

■1.  Frame  time  (time  for  (>•!  iterations  to  execute), 

.A.  Total  number  of  frames,  and 

G.  DMA  number  the  simulation  is  synchronizeil  to. 

The  DIRECTOR  outputs  include  task  (iriorities,  siiecial  event  timini;,  etc.,  to  the 
DEt'-lO  Real-Time  Executive.  Trackinn  information  is  sent  to  the  ('RT  dis[)lay  such  that  the 
operator  is  aware  of  progress  and  intermediate  results.  Traceback  messaues  are  extensive  in 
non-real-time  simulations  with  .sen.se  switches  on. 

The  DIHEtTOR  interfaces  with  the  real-time  clock  throunh  assembly  lannuaKC  (ironram 
SIMGO  and  em)>loys  a time  slice  conce))t  for  sequencmn  nuHlels  as  imiilemented  in 
subroutine  ('.Md’. 

2‘»G 
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2.6.2  Simulation  Model  Set  Description 


Onorally.  a jjivon  simulation  is  configured  by  selecting  appropriate  applications  model 
libraries  representative  of  either  F-16  or  A7  tactical  fighter  scenarios.  As  discussed 
previously,  alternate  applications  models  may  In?  user  supplied,  providing  proper  program 
interface  is  maintained.  This  .section  delineates  model  sets  currently  available  and  includes 
individual  model  descriptions  for  the  F-16  library  developed  by  (Jeneral  Dynamics.  The 
discussion  is  inUmtionally  brief  and  the  user  is  referred  to  the  references  for  more  detail. 

The  F-16  model  set  developed  for  AFAL  by  General  Dynamics  includes  the  following 
resident  modules: 

Airframe, 

Flight  Control  System, 

Air  Data  Computer, 

Accelerometers  and  Gyros, 

Simulated  Pilot, 

Synthetic  Mission  Generator  Model, 

Target  Simulator, 

Attack  Radar, 

Radar  Altimeter, 

Random  Noise  and  Error  Generator, 

Relative  Geometry, 

Weather, 

Atmosphere, 

Reference  Model  for  INS  Control, 

Inertial  Reference  Unit,  and 
Flux  Valve. 

Figure  2.6.2-1  depicts  the  major  paths  for  transferring  data  between  the  various  models. 
The  A7  model  acquired  from  the  Naval  Weapons  Center  at  China  Lake,  California,  has  been 
adapted  for  AVSIM.  Approximately  23  modules  are  resident  on  the  DEC-10  host.  Of  these, 
13  have  been  selected  by  AFAL  to  represent  the  DAIS  simulation  scenario.  These  are: 

Airframe, 

Aerodynamic  Model, 

Propulsion, 

Earth, 
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Inerti**!  Measurement  System, 
Ati.  ..here. 

Target, 

Radar  Altimeter, 

Forward  Looking  Radar, 

Air  Data, 

Doppler,  and 
TACAN. 


I 2.6.2.1  Airframe  (AFM1) 

I The  Airframe  model  provides  the  capability  to  evaluate  the  effects  of  airframe  dynamics 

I on  system  operation.  The  model  utilizes  linear  aerodynamic  coefficients  to  provide  vehicle 

I dynamics  for  six  degrees  of  freedom.  It  incorporates  Mach  number  variations  of  the 

I aerodynamic  coefficients  and  Mach  and  altitude  variations  of  the  flexibility  factors.  Variable 

' gross  weight  and  moments  of  inertia  can  be  included  through  fuel  flow  integration  and  store 

configuration  status.  Figure  2.6. 2.1-1  is  an  Input/Output  Block  Diagram  of  AFMl  with  the 
source  of  each  input  listed  on  the  left  while  the  disposition  of  each  output  is  listed  on  the 
right.  Additional  Input/Output  nomenclature  definition  is  contained  in  Table  2.6.2. 1-1 
below. 

I 

2.6.2.2  Flight  Control  System  Model  (FCS) 

FCS  is  the  mathematical  model  of  the  flight  control  system  electronics,  which  includes 
I augmentation  (CAS),  stability  augmentation  (SAS),  and  a command  following  autopilot. 

' The  CAS  and  SAS  systems  are  provided  to  augment  the  control  and  stability  of  the  basic 

; airframe.  The  command  following  autopilot  accepts  commands  in  attitude  and  altitude  for 

vehicle  control  when  the  cockpit  simulator  is  not  used.  FCS  also  contains  a simulation  of 
the  mechanical  control  surface  actuators. 

The  major  functions  and/or  procedures  contained  in  the  FCS  subprogram  are: 

I 

1.  Stability  and  Control  Augmentation,  and 
! 2.  Command  Following  Autopilot. 

The  stability  and  control  augmentation  function  provides  the  compensation  networks  and 
' feedback  paths  to  improve  vehicle  control  and  to  provide  the  proper  stability  characU'ristics. 

Pitch  rate,  normal  acceleration,  and  angle  of  attack  provide  the  feedback  in  the  longitudinal 
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TABLE  Z12.1-1.  AFM1  INPUT/OUTPUT  NOMENCLATURE 


Input  Oata 

FORTRAN  Nama 

Math  Symbol 

Oawription 

Units 

ALROF 

Aileron  deflection 

degree 

OELTAF 

Flap  deflection 

degree 

DELTHA 

*Ha 

Differential  horizontal  tail  deflection 

degree 

DELTSB 

*$B 

Speedbreke  deflection 

degree 

G 

9 

Earth  gravity 

ft/s^ 

H 

h 

Airplane  eltitude  (double  precision) 

ft 

PRESRA 

P/Po 

Air  pressure  ratio 

RORO 

»r 

Rudder  deflection 

degree 

THRCON 

Throttle  input  from  cockpit 

TIMEX 

t 

Elapsed  time  since  start  of  simulation  run 

s 

TLOF 

Horizontal  tail  deflection 

degree 

VELC 

Vc 

Airplane  velocity  command 

ft/s 

VS 

a 

Speed  of  sound 

ft/s 

WA 

- 

Wander  angle 

degree 

Output  Oita 


All 

•j) 

Direction  cosine  matrix  element 

A12 

*12 

Direction  cosine  matrix  element 

A13 

*13 

Direction  cosine  matrix  element 

A23 

*23 

Direction  cosine  matrix  element 

A33 

*33 

Direction  cosine  matrix  element 

ACCNY 

Aw 

^CG 

Lateral  acceleration  at  the  C.  G. 

9 

ACCNZ 

Au 

"CG 

Normal  Kcalaration  at  the  C.  G. 

9 

ALPHD 

a 

Angle  of  attack 

degree 

AMACH 

M 

Mach  no. 

BETAD 

Sideslip  angle 

degree 

EOSQ 

<Eo>2 

‘^’’2 

Eg  squared 

E1SQ 

E^  squared 

E2SQ 

E2  squared 

E3SQ 

(Ej)^ 

E3  squared 

PHI 

0 

Airplane  roll  angle 

rad 

PHID 

0 

Airplane  roll  angla 

dagrsa 

PSI 

0 

Airplane  yaw  angle 

red 

QOOT 

q 

First  time  darivativa  of  q 

rad/s^ 

ROOT 

f 

First  time  darivativa  of  r 

rad/s^ 

SAVEP 

p 

Body  axis  roll  rata 

rad/s 

SAVED 

q 

Body  axis  pitch  rata 

rad/s 

SAVER 

r 

Body  axis  yaw  rata 

red/s 

SAVEU 

u 

X axis  airplane  velocity  WRT  earth 

hit 

SAVEV 

V 

Y axis  airplane  velocity  WRT  earth 

hit 

SAVEW 

TE0E1 

TE0E2 

w 

Z axis  airplane  velocity  WRT  earth 

Two  X EO  X El 

Two  X EO  X E2 

hit 
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TABLE  2.e.2.1-1.  AFM1  INPUT/OUTPUT  NOMENCLATURE  (con.) 


Output  Data 

FORTRAN  Nama 

Math  Symbol 

OaKiiption 

Units 

TE0E3 

Two  X EO  X E3 

TE1E2 

Two  X El  X E2 

TE1E3 

Two  X El  X E3 

TE2E3 

Two  X E2  X E3 

THETA 

0 

Airplane  pitch  angle 

rad 

THETAD 

0 

Airplane  pitch  angle 

degree 

UDOT 

u 

X axis  airplane  acceleration  WRT  earth 

tt/s^ 

VDOT 

V 

Y axis  airplane  acceleration  WRT  earth 

tl/s^ 

WOOT 

w 

Z axis  airplane  acceleration  WRT  earth 

It/s^ 

channel,  while  yaw  rate,  roll  rate,  and  lateral  acceleration  are  uswl  in  the  lateral-directional 
ihannel. 

The  command  following  autopilot  accepts  guidance  signals  from  the  SMCiM  to  fly  the 
airplane  when  the  cockpit  is  not  utilized.  The  autopilot  commands  normal  acceleration  and 
roll  rate  through  the  control  augmentation  system  to  null  the  guidance  signals.  The  value  of 
the  logic  keys  KEYLAP  and  KEYDAP  determine  if  the  autopilot  is  utilizetl  and,  if  so,  which 
command  signals  from  the  SMGM  to  implement.  The  logic  definition  is  shown  below. 

KEY  LAP  (Key  Longitudinal  Autopilot) 

= 1 No  longitudinal  autopilot 
=2  .Altitude  command 
=3  Pitch  attitude  command 
»4  Incremental  pitch  attitude  command 

KEYDAP  (Key  Directional  Autopilot) 

»1  No  directional  autopilot 
=2  Bank  angle  command 
=3  Heading  command 
’’4  Incremental  heading  command 

Figure  2.6. 2.2-1  is  an  Input/Output  Block  Diagram  of  FCS  with  the  source  of  each  input 
listed  on  the  left  while  the  disposition  of  each  output  is  listed  on  the  right.  Additional 
Input/Output  nomenclature  definition  is  contained  in  Table  2.6.2. 2-1. 
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TABLE  tB.2.M.  FCS  IMPUT/OUTFUT  NOMENCLATURE 

Input  Data 

FORTRAN  Nama 

Math  Symbol 

OoKription 

Units 

ALPHO 

a 

Angla  of  attack 

dagree 

ALTC 

Altitude  command 

ft 

ANA 

^N* 

Normal  accalaration  at  tha  accalaromatar 

g 

ANCC 

Normal  accalaration  command 

g 

AYA 

Ay* 

Lateral  accalaration  at  tha  accalaromatar 

ft/s^ 

BRO 

Spaadbraka  deflection  angle  from  cockpit  simulator 

degree 

CFLAPS 

Flap  command  from  cockpit  simulator 

OASIN 

Aileron  stick  input  from  cockpit  simulator 

DATRIM 

Aileron  trim  input  from  cockpit  simulator 

red 

DESIN 

Elavator  stick  input  from  cockpit  simulator 

OETRIM 

Elarator  trim  input  from  cockpit  simulator 

rad 

ORSIN 

Rudder  padal  input  from  cockpit  simulator 

ORTRIM 

Ruddar  trim  input  from  cockpit  simulator 

red 

H 

h 

Airplane  altitude 

ft 

PG 

P* 

Airplane  roll  rate  from  ACGY 

degree/s 

PHIC 

Roll  command  signal 

degree 

PHIO 

Airpitne  roll  angle 

degree 

PRAL 

Psi 

Static  pressure  from  ADC 

Ib/ft^ 

PSIC 

Heading  command 

degree 

PSIGT 

'*'GT 

Ground  track  heading 

dagree 

QCN 

1c 

Impact  prassura  from  AOC 

Ib/ft^ 

QG 

1* 

Airplane  pitch  rata  from  ACGY 

degree/s 

RG 

r* 

Airplane  yaw  rate  from  ACGY 

degree/s 

THETAD 

<(> 

Airplane  pitch  angle 

degree 

THETC 

Pitch  command 

degree 

Output  Data 

ALRDF 

*a 

Aileron  deflection 

degree 

DELTAF 

*F 

Flap  daflaction 

degree 

OELTHA 

^Ha 

Differential  horirontal  tail  deflection 

degree 

OELTSB 

*SB 

Speedbrake  deflection 

degree 

RDRO 

*r 

Rudder  deflection 

dagree 

TLDF 

Horicontal  tail  deflection 

degree 

2.6.2.3  Air  Data  Computer  Model  (ADC) 

Tho  ADC  suliprotO’am  is  the  matliematical  model  of  the  air  data  computer  mid 
innHirtant  air  data  sensor  dynamics.  The  ability  to  degrade  their  performance  of  the  model 
through  the  use  of  the  NERR  model  on  sensor  inputs  is  include<l. 
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The  purpose  of  the  Air  l>ata  Computer  model  mathematical  operation  is  to  provide  air 
data  sensor  information  to  an  actual  air  data  computer  (hanlwan*)  ami,  or  use  the  same 
information  in  simulating  air  data  computer  functions.  The  major  functions  in  the  .-MX' 
subprottram  area  an'  to: 

1.  Provide  the  air  data  sensor  inputs: 

Air  Data  Computer  Model, 

Static  pressun', 

Total  pn'ssun',  and 
Indicateti  temperatun*;  and 

2.  Calculate  the  air  data  outputs: 

Pressure  altitude, 

Pressure  altitude  rate, 

Mach  numt>er, 
lYue  airspee<l. 

Fret'  air  temperatun',  and 
Indicatt'd  airspet'd. 

The  air  data  senstirs  provide  the  signals  necessarj’  for  tire  air  data  computer  to  calculate 
its  output  quantities.  Idealizetl  sensor  signals  an'  either  n'ceivetl  from  other  motlels  or 
calculated  from  input  quantities. 

Static  pressure  and  fn'e  air  temperatun'  come  from  the  .Atmosphere  motlel  as  standard 
day  table  look-up  values.  .Angle  of  attack  and  sideslip  angles  are  calculated  in  the  .Airfnune 
model  from  airplane  velocity  components.  The  other  air  data  input,  impact  pressure,  is 
calculattHl  in  the  sensor  model  as  a flinction  of  the  Mach  number  obtained  from  the  airframe 
model.  After  these  signals  an'  shapt'd  in  tire  sensor  module  they  enter  tlie  .Air  Data 
Computer  module  as  sensor  output  signals.  These  signals  an'  driven  through  a lag  transfer 
function  to  simulate  system  lags.  Sensor  noise  and  bias  errors  may  Ih'  incorj>oratt\l  by 
setting  IRNADC  = 1 and  defining  the  rms  noise  and  bias  levels. 

The  air  data  computer  calculates  the  desired  air  data  output  parameters  from  the  sensor 
signals.  These  computations  are  performed  in  flight  by  an  amilog  or  digital  computer 
utilizing  equations  similar  to  those  implemented  in  this  simulation. 

Figure  2.6.2.3-1  is  an  Input/Output  Block  Diagram  of  ADC  with  the  source  of  each 
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input  listed  on  the  left  while  the  disposition  of  each  output  is  listed  on  tlie  right.  Additional 
Input/Output  nomenclature  definition  is  contained  in  Table  2. 6. 2. 3-1  below. 


2.6.2.4  Accalerometers/Gyros  Model  (ACGY) 

ACGY  simulates  the  linear  accelerometers  and  gyros  by  corrupting  “true"  acceleration, 
roll,  pitch  and  yaw.  It  considers  sensor  location  on  the  airplane,  and  significant  sensor 
characteristics  (deadbands,  limits,  noise,  and  bias).  These  characteristics  may  be  specified  or 
bypassed  by  setting  the  logic  key  KEYAG  to  one  or  zero,  respectively. 


The  Accelerometers  and  Gyros  sensor  simulation  consist  of  three  submodules.  One 
submodule  accounts  for  the  effects  of  locating  the  accelerometers  at  other  than  the  center 
of  gravity  of  the  vehicle.  This  module  is  utilized  regardless  of  the  value  of  KEYAG.  The 
other  two  submodules  contain  the  significant  sensor  characteristics,  which  may  be  specified 
or  bypassed.  Random  noise  and  bias  errors  are  included  in  the  model  by  specifying  the 
appropriate  logic  keys  and  the  rms  noise  and  bias  levels.  Noise  and  bias  are  specified  for  each 
individual  sensor. 


TABLE  2.6.2.3-1.  ADC  INPUT/OUTPUT  NOMENCLATURE 


Input  Data 

FORTRAN  Niim 

Math  Symbol 

Dascription 

Units 

ALPHO 

a 

Angle  of  attack 

degree 

AMACH 

M 

Mach  no. 

BETAO 

» 

Sideslip  angle 

degree 

PRES1 

p, 

BaronMtric  praisura 

Ib/ft^ 

TEMP 

Tm 

Air  temperature 

"R 

Output  Data 

AEAS 

Vi* 

AOC  indicated  air  speed 

kt 

ALPSTR 

o* 

ADC  angle  of  attKk 

degree 

BETSTR 

0* 

AOC  sideslip  angle 

degree 

HPOSTR 

Hp* 

AOC  prassure  altituda  rata 

ft/s 

HPSTH 

Hp* 

AOC  pressure  altitude 

ft 

MSTR 

M* 

AOC  Mach  no. 

PRAL 

P|i 

AOC  static  pressure 

Ib/ft^ 

QCN 

qc 

ADC  impact  pressure 

Ib/ft^ 

TMAL 

TmR. 

AOC  free  air  temperature  (Rankine) 

°R 

TMCSTR 

Tmc* 

AOC  free  air  temperature  (Centigrade) 

'C 

VTSTR 

''t* 

ADC  true  air  spaed 

kt 
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ACtiY  first  determines  ‘‘true"  (i.e.,  uncomipted)  values  of  the  normal  acceleration  ANl 
and  the  lateral  accelenition  AYl  at  the  sensor  location,  using  the  stMisor  displacements 
OXAN  and  DYAN  from  the  center  of  gravity  of  the  plane,  and  Uie  true  values  of  normal 
and  lateral  acceleration  lat  the  center  of  gravity)  input  from  the  Airframe  Model.  It  also 
Slides  the  int'ut  true  values  of  the  angular  roll  rate  p,  pitch  rate  i).  and  yaw  rate  r from 
radians. second  to  degrees/seiond.  ACGY  then  corrupts  ANl.  AYl.  and  piUh,  roll,  and  yaw 
rates  (QO,  PG.  and  RG)  by  introducing  errors  due  to  deadbands,  limits,  noise,  and  bias.  I'he 
subroutine  contains  options  to  bypass  the  enor  computations.  The  options  are  selected  by 
setting  the  flags  KKY.AG  and  IKNAEG,  as  follows: 

1.  If  K.\Y.\G=1.  errors  bastH.1  on  the  .sensor  deadbands  and  limits  an*  computed. 

2.  If  KKY.\G=0,  deadbands  are  not  computed. 

If  1RN.AF.G=1,  errors  based  on  the  sensor  noise  and  bias  are  comtaited. 

4.  If  1RN.\KG=0,  the.se  errors  an'  not  computed. 

The  accelerations  (either  normal  or  lateral)  as  corrupted  by  the  sensor’s  ile;idband  are 
determiiuHi  by  the  function  OBNO.  Using  this  function,  the  acceleration  is  set  to  zero  if  the 
in()ut  true  value  of  ai’i’cleration  i.s  « it)iiii  the  tieadbaiui.  If  Die  input  true  v;ihu'  is  outside  the 
deadband,  the  output  value  is  found  by  subtracting  the  deadband  from  the  input  true  value. 

Figure  2. 6. 2. 4-1  is  an  Input  Output  Block  Diagram  of  .-VCGY  with  the  soun-e  of  eacli 
input  listeil  on  the  left  while  the  ilisposition  of  each  out[>u(  i.s  listed  on  the  right.  .Atlditional 
Input 'Output  nomenclatun'  definition  is  contained  in  Table  2. (>.2.4-1  below. 

2.6.2.5  Simulated  Pilot  Model  (SIMP) 

This  model  provides  simulati'tl  pilot  steering  dynamics  to  modify  the  steering  commimds 
to  the  flight  control  system  when  the  mission  is  directwl  by  the  synthetic  mission  generator 
(SMGM).  The  Simulated  Pilot  model  for  the  simulation  program  is  repri  sentwl  as  a single 
miKlule.  .Autojiilot  guidance  command  signals  an'  modified  in  the ’pilot  nuHlel  to  simulate 
the  human  pilot  steering  ilynamics.  The  model  includes  a transport  lag,  a neuromuscular  lag, 
a lead-lag  function  and  a gain  t>arameter.  .Ml  inputs  to  the  simulatt'tl  pilot  originate  in  the 
Synthetic  Mission  Generator  model.  Subroutine  SIMP  is  called  by  subroutine  DIR  when 
SIMP  is  required.  SIMP  communicates  with  SMGM,  C.-\LP  and  FCS  through  common 
variables.  Outputs  from  SIMP  are  the  command  signals  which  an-  put  into  the  common  data 
file  and  subsequently  are  available  to  the  flight  control  system. 


TABLE  2.6.2.4  1.  ACGY  INPUT/OUTPUT  NOMENCLATURE 


Input  Diti 

FORTRAN  Nimt 

Mtth  Symbol 

Dtscription 

Units 

ACCNY 

Lateral  acceleration  at  the  C.  G. 

9 

ACCNZ 

^■^CG 

Normal  acceleration  at  the  C.  G. 

9 

G 

9 

Eanh  gravity 

ft/$^ 

QOOT 

q 

Firtt  time  derivative  of  q 

rad/s^ 

rad/s^ 

ROOT 

f 

First  time  derivative  of  r 

SAVEP 

p 

Body  axis  roll  rate 

rad/s 

SAVEQ 

q 

Body  axis  pitch  rate 

rad/$ 

SAVER 

r 

Body  axis  yaw  rate 

rad/s 

Output  D»ti 


ANA 

An* 

Normal  accaleration  from  ACGY 

9 , 

AYA 

Ay* 

Lateral  acceleration  from  ACGY 

ft/$^ 

PG 

P* 

Airplane  roll  rate  from  ACGY 

degree/s 

QG 

q* 

Airplane  pitch  rate  from  ACGY 

dagrae/s 

RG 

r* 

Airplane  yaw  rate  from  ACGY 

d«gree/s 

2.G.2..'i-l  is  an  Input/Output  Block  Duifiram  of  SIMP  with  tho  source  of  each 
input  lisUnl  on  the  left  while  the  disposition  of  each  output  is  listed  on  the  rinht.  Additional 
Input/Output  nonienclatun*  tlefinition  is  contained  in  Table  2. 6. 2. 5-1  below. 

2.6.2.6  Synthetic  Mission  Generator  Model  (SMGM) 

The  SMGM  controls  the  generation  of  simulated  aircraft  movement  characteristics  when 
there  is  no  “real”  man  in  the  loop.  Guidance  Command  outputs  can  be  use<l  to  directly 
drive  the  Autopilot  model  (Option  1)  or  they  can  be  routed  through  a Simulated  Man  model 
(Option  11)  in  order  to  introduce  the  dynamics  of  pilot  response  delays.  Options  for  SMGM 
profiles  are  as  follows: 

1.  OPTION  1 

In  Option  I the  SMGM  generates  a “flight  environment"  based  on  an  input  flight  profile. 
In  this  option,  the  airframe  model  is  used  to  supply  the  following  inputs  to  the  Refer- 
ence Model  for  Inertial  Navigation  (RMIN); 

a.  air{>lane  pitch  angle. 
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TABLE  2.6.2.5-t.  SIMP  INPUT/OUTPUT  NOMENCLATURE 


Input  Oats 

FORTRAN  NauM 

Math  Symbol 

Oatcription 

Units 

ALTC 

Altituda  command 

h 

PHIC 

Oc 

Roll  command 

dagrae 

PSIC 

'‘'c 

Haading  command 

dagrea 

THETC 

Pitch  command 

dagraa 

TIMEX 

Elapnd  tima  tinea  start  of  simulation  run 

t 

Output  Data 

ALTC 

K 

Altituda  command 

h 

PHIC 

Roll  command 

dagraa 

PSIC 

*c 

Haading  command 

dagraa 

THETC 

Pitch  command 

dagraa 

b.  airplane  roll  anule, 

c.  airplane  yaw  angle, 

cl.  three  body  linear  accelerations, 

e.  three  body  linear  rates, 

f.  three  body  angular  rates, 

g.  true  airspeed, 

h.  five  direction  cosine  matrix  elements,  and 

i.  ten  quaternion  parameters. 

The  flight  control  model  is  used  to  drive  the  airframe  model,  and  the  autopilot  is  used  to 
drive  the  flight  control  model.  Commands  from  the  SMGM  to  the  autopilot  are; 

a.  ALTC  — altitude  command, 

b.  ANCC  — acceleration  command, 

c.  PHIC  — roll  command, 

d.  PSIC  — heading  command,  and 

e.  THETC  — pitch  command. 


In  addition  to  the  above  commands,  the  velocity  command,  VELC,  from  SMGM  is 
channeUxl  directly  to  the  airframe  where  VELC  is  tlv*  control  input  for  the  autothrottle. 


2.  OPTION  n 

Option  II  is  the  same  as  Option  1 except  that  the  response  delays  of  a simulated  pilot 

shall  be  applied  to  commands  prior  to  feeding  the  commands  to  the  autopilot. 

Figure  2.6. 2. 6-1  is  an  Input/Output  Block  Diagram  of  SMGM  with  the  source  of  each 
input  listed  on  the  left  while  the  disposition  of  each  output  is  listed  on  the  right.  Additional 
Input/Output  nomenclature  definition  is  contained  in  Table  2. 6. 2. 6-1  below. 

2.6.2.7  Target  Simulation  (TGT) 

The  Target  model  is  a service  model  that  functions  with  the  Relative  Geometry  model. 
Weather  model  and  the  sensor  models.  The  function  of  the  Target  model  is  to  permit 
simulated  target  positions  and  signatures  to  be  sent  to  the  Target  Detection  Sensor  models 
(i.e.,  radar  and  E/O).  The  target  characteristics  simulated  include  target  and  background 
radar  cross  sections  and  background  radiances.  The  model  functions  include  derivations  of 
target  positions  from  movement  profiles  for  the  simulation  of  moving  targets  and 
computation  of  radar  background  cross  sections.  Specifically,  it  performs  the  following 
logical  functions; 

1.  It  provides  the  location  of  each  non-moving  target  to  the  Relative  Geometry  model. 

2.  It  computes  and  provides  the  location  of  each  moving  target  to  the  Relative  Geom- 
etry model. 

3.  It  computes  the  radar  ground  return  cross  section  to  be  supplied  to  the  Radar 
model. 

4.  It  provides  the  logic  to  control  the  comparison  of  target  location  with  sensor 
coverage  in  order  to  minimize  the  number  of  times  the  in  coverage  test  must  be 
performed. 

The  location  of  each  non-moving  target  is  TGT  model  input  data  and  is  stored  in  the 
data  common  where  it  is  available  for  use  by  the  Relative  Geometry  model.  The  non-moving 
target  location  data  is  provided  in  terms  of  latitude,  longitude,  and  altitude  above  sea  level. 
The  target  model  shall  generate  the  current  location  of  the  moving  targets  in  accordance 
with  a moving  target  profile  which  is  stored  as  initialization  data.  The  initial  position  of  the 
target  is  specified  in  terms  of  latitude  and  longitude.  The  target  profile  shall  commence 
when  the  initial  point  is  within  some  maximum  range  RMAX2.  The  current  location  of  the 
moving  target  is  then  computed  and  passed  to  relative  geometry  in  terms  of  latitude, 
longitude,  and  altitude. 
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TABLE  2.6.2.6-1.  SMGM  INPUT/OUTPUT  NOMENCLATURE 


i 


f 

i 

( 


r 


Input  Ditn 

FORTRAN  Nami 

Math  Symbol 

Dascription 

Units 

G 

9 

Earth  gravity 

ft/s^ 

TIMEX 

t 

Elapsed  time  since  start  of  simulation  run 

s 

Output  Data 

All 

*11 

Direction  cosine  matrix  element 

A12 

*12 

Direction  cosine  matrix  element 

A13 

*13 

Direction  cosine  matrix  element 

A23 

*23 

Direction  cosine  matrix  element 

A33 

*33 

Direction  cosine  matrix  element 

ALTC 

Altitude  command 

ft 

ANCC 

Normal  acceleration  command 

9 

EOSQ 

Eq  squared 

E1SQ 

E^  squared 

E2SQ 

E2  squared 

E3SQ 

(E3)2 

E2  squared 

PHI 

0 

Airplane  roll  angle 

rad 

PHIC 

Roll  command  signal 

degree 

PSI 

0 

Airplane  yaw  angle 

rad 

PSIC 

'^C 

Heading  command 

degree 

SAVEP 

p 

Body  axis  roll  rate 

rad/s 

SAVED 

q 

Body  axis  pitch  rate 

rad/s 

SAVER 

r 

Body  axis  yaw  rate 

rad/s 

SAVEU 

u 

X axis  airplane  velocity  WRT  earth 

ft/s 

SAVEV 

V 

Y axis  airplane  velocity  WRT  earth 

ft/s 

SAVEW 

w 

1 axis  airplane  velocity  WRT  earth 

ft/s 

TEOEl 

- 

Two  X EO  X El 

TE0E2 

- 

Two  X EO  X E2 

TE0E3 

- 

Two  X EO  X E3 

TE1E2 

- 

Two  X El  X E2 

TE1E3 

- 

Two  X EO  X E3 

TE2E3 

- 

Two  X E2  X E3 

THETA 

e 

Airplane  pitch  angle 

rad 

THETC 

\ 

Pitch  command 

degree 

UA 

UA 

Trua  air  speed 

ft/s 

UDOT 

u 

X axis  airplane  acceleration  WRT  earth 

ft/s^ 

VOOT 

V 

Y axis  airplane  acceleration  WRT  earth 

ft/s^ 

VELC 

Vc 

Airplane  velocity  command 

ft/s^ 

WDOT 

w 

Z axis  airplane  acceleration  WRT  earth 

ft/s^ 
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Figure  2.6. 2.7-1  is  an  Input/Output  Block  Diagram  of  TGT  with  the  source  of  each 
I input  listed  on  the  left  while  the  disposition  of  each  output  is  listed  on  the  right.  Additional 

I Input/Output  nomenclature  definition  is  contained  in  Table  2.6. 2. 7-1  below. 

i 

[ 2.6.2.8  Attack  Radar  (ARS) 

The  Attack  Radar  model  is  a model  that  functions  with  the  service  and  reference  models 
’ to  produce  a simulation  of  a generic  attack  radar.  The  model  simulates  the  following  modes 

j and  functions  of  the  attack  radar: 

! 

1.  Air-to-Ground  Search, 

2.  Air-to-Ground  Ranging, 

3.  Air-to-Ground  Level  Bombing/Fixtaking,  and 

4.  Air-to-Air. 

In  the  air-to-ground  search  mode,  ARS  provides  the  following  functions: 

1.  Drives  the  antenna  in  a simulated  search  scan, 

2.  Determines  signal  level  of  any  targets  within  the  radar  beam, 

3.  Computes  radar  range  to  target,  and 

4.  Computes  noise  output  signal,  weather  signal,  and  signal  + background  + noise. 

In  the  air-to-ground  ranging  mode,  ARS  provides  the  following  functions:  ] 

1.  Generates  antenna  azimuth  and  elevation  pointing  signals, 

2.  Drives  the' antenna  to  the  simulated  azimuth  and  elevation  angles, 

3.  Determines  signal  level  returned  from  the  target, 

4.  Computes  radar  range  to  target,  and 

5.  Computes  noise  output  signal,  weather  signal,  and  signal  + background  + noise. 

In  the  air-to-ground  level  bombing/ f betaking  mode,  ARS  provides  the  following 
functions: 

1.  Accepts  cursor  positioning  commands  from  the  cockpit, 

2.  Drives  the  antenna  in  a simulated  search  scan, 

3.  Determines  signal  level  of  any  targets  within  radar  beam, 

4.  Computes  radar  range  to  target,  and 

5.  Computes  noise  output  signal,  weather  signal,  and  signal  + background  + noise. 


316 


r 


"wr 


TABLE  2.6.2.7-1.  TGT  INPUT/OUTPUT  NOMENCLATURE 


Input  Data 

FORTRAN  Namt  Math  Symbol 

Oascription 

Units 

TIMEX  t 

Elapsed  time  since  start  of  simulation  run 

s 

TRANCE 

Range  to  target 

ft 

Output  OatB 


BXSEC 

Radar  background  cross  section 

ft2 

NTGT 

Number  of  targets  defined 

ON 

- 

Target  in-coverage  flag 

REFL 

■^R 

Radar  rain  reflection 

TARALT 

Target  altitude 

h 

TARLAT 

- 

Target  latitude 

rad 

TARLON 

- 

Target  longitude 

rad 

TXSEC 

Target  radar  cross  taction 

ft^ 

In  the  air-to-air  mode,  ARS  provides  the  following  functions: 

1.  Determines  which  air-to-air  submode  is  active  (A/A  search,  A/A  acquisition/manua) 
designate,  A/A  acquisition/autodesignate,  A/A  track); 

2.  A/A  search 

a.  Generates  antenna  scan  positions  (single-bar  scan  or  multi-bar  scan), 

b.  Determines  signal  level  of  any  targets  within  radar  beam, 

c.  Computes  radar  range  to  target,  and 

d.  Computes  noise  output  signal,  weather  signal,  and  signal  + background  + noise; 

3.  A/A  acquisition/manual  designate 

a.  Accepts  cursor  positioning  signal  from  cockpit, 

b.  Drives  antenna  to  designated  position, 

c.  Determines  signal  level  of  any  target  within  radar  beam, 

d.  Computes  radar  range  to  target,  and 

e.  Computes  noise  output  signal,  weather  signal,  and  signal  + background  + noise; 

4.  A/ A acquisition/autodesignate 

a.  Places  cursors  upon  nearest  target, 

b.  Drives  antenna  to  designated  position, 

c.  Determines  signal  level  of  any  targets  within  radar  beam, 

d.  Computes  radar  range  to  target,  and 
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5.  A/ A track 

a.  Locks  antenna  on  predesipiated  target, 

b.  Determines  signal  level  of  target, 

c.  Computes  radar  range  to  target,  and 

d.  Computes  noise  output  signal,  weather  signal,  and  signal  + background  + noise. 

« 

Figure  2. 6. 2. 8-1  is  an  Input/Output  Block  Diagram  of  ARS  with  the  source  of  each 
input  listed  on  the  left  while  the  disposition  of  each  output  is  listed  on  the  right.  Additional 
Input/Output  nomenclature  definition  is  contained  in  Table  2. 6. 2. 8-1  below. 

2.6.2.9  Radar  Altimeter  (RALT) 

The  Radar  Altimeter  model  is  a sensor  model  that  functions  with  the  service  and 
reference  models  to  produce  a simulation  of  a generic  radar  altimeter.  Provision  is  made  to 
vary  the  radar  altimeter  antenna  parameters  and  the  roll  and  pitch  limits  through  which  the 
altimeter  will  function  without  large  error.  Provision  is  made  to  simulate  both  random  and 
bias  errors . 

The  inputs  to  the  radar  altimeter  consist  of  true  values  of  airplane  pitch  and  roll  angles, 
altitude  above  sea  level,  elapsed  time,  and  altimeter  on/off  signal.  RALT  begins  by 
determining  whether  aircraft  attitude  enables  an  accurate  measurement  by  a radar  altimeter. 
If  the  aircraft  is  to  receive  an  altitude  measure,  first  the  true  value  of  altitude  above  tlie 
earth  plane  is  determined;  second,  this  value  is  corrupted  as  in  a hardware  radar  altimeter; 
and  third,  an  “altitude-good”  is  returned  to  the  system.  Output  data  from  the  radar 
altimeter  model  consists  of  the  radar  altitude  above  terrain  and  the  output-good  signal.  All 
data  is  transferred  via  common  blocks.  Figure  2.6. 2.9-1  is  an  Input/Output  Block  Diagram 
of  RALT  with  the  source  of  each  input  listed  on  the  left  while  the  disposition  of  each 
output  is  listed  on  the  right.  Additional  Input/Output  nomenclature  definition  is  contained 
in  Table  2. 6.2. 9-1  below. 

2.6.2.10  Random  Noise  and  Error  Generation  (NERR) 

The  function  of  the  Normal  Error  Generator  is  to  provide  random  and  bias  error  variates 
to  perturbate  simulation  signals  in  other  models.  The  model  employs  a pseudo-random 
number  generator  to  produce  ihe  normal  variates  generated  and  stored  in  an  off-line  (non- 
real-time)  initialization  program.  The  real-time  program  calls  the  normal  variates  from 
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TABLE  2.I.2.B-1.  ARS  INPUT/OUTPUT  NOMENCLATURE 


Input  Data 

FORTRAN  Nama 

Math  Symbol 

Dascription 

Units 

ALT 

h 

Airplane  altitude 

ft 

BXSEC 

“B 

Radar  background  cron  saction 

ft^ 

ITAR 

Salectad  target 

RACLT 

- 

Length  of  LOS  ngment  to  target  in  layer  2 

ft 

RAPRT 

- 

Length  of  LOS  segment  to  target  in  layer  3 

ft 

REEL 

Radar  rain  reflection  coefficient 

TARALT 

Target  altitude 

ft 

TAZ 

- 

Target  body  azimuth  angle 

rad 

TEL 

- 

Target  body  elevation  angle 

rad 

TIMEX 

t 

Elapsed  time  since  start  of  simulation  run 

s 

TRANCE 

- 

Range  to  target 

ft 

TXSEC 

“T 

Target  radar  cross  section 

ft^ 

Output  Oatu 


ANAZPO 

_ 

Azimuth  position  of  antenna 

rad 

ANELPO 

- 

Elevation  position  of 

rad 

ONOISE 

- 

Output  noise  voltage 

V 

RAGOOD 

- 

Radar  good  flag 

RAPO 

- 

Output  range  to  target 

ft 

SIGOUT 

- 

Output  signal  voltage 

V 

SIGR 

- 

Weather  signal  output  voltage 

V 

STNR 

- 

Signal-to-noise  ratio 

TABLE  Z6.2.9-1.  HALT  INPUT/OUTPUT  NOMENCLATURE 


Input  Data 


FORTRAN  Name 

Math  Symbol 

Oescription 

Units 

H 

h 

Airplane  altitude 

ft 

PHI 

0 

Airplane  roll  angle 

rid 

RAHSTA 

- 

Radar  altimeter  on/off  signal 

THETA 

e 

Airplane  pitch  angle 

nd 

TIMEX 

t 

Elapsed  time  since  start  of  simulation  run 

s 

Output  Data 

RAH 

H 

Radar  altimeter  output  altitude 

ft 

lALTGO 

- 

Radar  altimeter  output-good  signal 
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sturan*’.  ivrforms  a si-aliiiK  oporation,  and  adds  Mio  l>ias  error  to  tiu'  vailed  error  variat4‘, 
Kau'h  variate  ealleil  by  the  normal  error  pro>jrain  is  essentially  independent  of  any  otlu'r 
variate  ealled  previously  or  subsequently. 

The  Normal  Krror  IJenerator  is  a .serv’iee  subproiiram  wbieb  is  ealliHl  whenever  any  of  the 
other  models  neetl  a normally  distribuUHl  random  number.  The  nenerat«\i  error  variates  are 
outputs  of  the  funetum  NKRU.  Kaeli  viu'iate  is  a siiqjle  number  that  eontains  the  random 
noise  eomponent  as  well  as  a bias  eomponent  tbat  establishes  the  mean  of  the  error.  Kinur«> 
2.tv‘2.10-l  IS  an  Input 'Output  Hloek  Diagram  of  NKRU  with  tbesouri'eof  eaeh  input  listi'tl 
on  the  left  while  the  disposition  of  eaeh  output  is  listed  on  the  rij;ht.  .Additional 
Input  Output  iioineiielat lire  definition  is  eontamiHl  in  Table  U.ti. 2.10-1  below. 


TABLE  2.6.2.10  1.  NERR  INPUT/OUTPUT  NOMENCLATURE 


Input  0«tl 

FORTRAN  Namt 

Math  Symbol 

Daicriptian 

Units 

BIAS* 

0 

Normal  variata  bias 

SIGM* 

Normal  variata  tcala  factor 

Output  Data 

NERR 

- 

Scalad  normal  variata  (raal  variable) 

* Arnumanu  ol  FUNCTION  NERR. 


2.6.2.11  Relative  Geometry  Model  (REGE) 

Ri'lative  Oeometry  eimiputes  the  "true"  Cartesian  eomponents.  a/.imuth  angles,  and 
elevation  atifth's  of  all  taivids  and  fixpoints.  I'he.se  eoonlinates  are  eomputiHl  in  the  loeally 
level  .system  aiul  in  the  airplane  body  system.  The  coordinates  are  computiHl  in  subroutiiu> 
R.ANO.  Subroutine  RKOK  defines  tbe  arnunient  list  for  H.\NC«.  lalls  R.ANCi.  and  pa.sses  tbe 
results  of  R.ANO’s  calculations  tji  the  proper  target  or  fixpoinl.  RKOK  also  contains  an 
I'xtrapolation  loop  which  updates  the  coordinate  values  between  I'alls  to  R.ANO. 

Ki|{ure  2.().2.11-1  is  an  Input'Output  Hlock  DiaKram  of  RKOK  with  the  source  i>feach 
input  listeil  on  the  left  while  the  disposition  of  each  output  is  listeil  on  the  rn;ht.  .Additional 
Input  tlutput  nomenclature  definition  is  contained  in  Table  2.t>.2.1 1 1 below. 
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TABLE  2.6.2.11-1.  REGE  INPUT/OUTPUT  NOMENCLATURE 


Input  Oita 

FORTRAN  Nimt 

Mith  Symbol 

OMcription 

Units 

C 

CB 

NFIX 

NTGT 

PX 

CB.j 

"x 

Locally  lival-to-aailh  direction  cosine  matrix 
Body-to-locally  level  direction  cosine  metrix 
Number  of  fixpoints  defined 

Number  of  targets  defined 

Vehicle  rate,  X axis 

rad/s 

PY 

Oy 

Vahicia  rata,  Y axis 

nd/s 

RM 

Bppt 

Bppx 

Range  to  prannt  position,  Z axis 

ft 

RPPX 

Range  to  pratant  position,  ^ axis 

ft 

RPPY 

”ppv 

Range  to  present  position,  Y axis 

ft 

TAR ALT 

Target  altitude 

ft 

TARLAT 

- 

Target  latitude 

rad 

TARLON 

- 

Target  longitude 

rad 

VXE 

Vxo 

X axis  velocity  WRT  earth 

ft/s 

VYE 

Vy. 

Y axis  velocity  WRT  earth 

ft/s 

VZ 

Z axis  valocity  WRT  earth 

ft/s 

ZALT 

Fixpoint  altitude 

ft 

ZLAT 

- 

Fixpoint  latitude 

rad 

ZLON 

- 

Fixpoint  longitude 

rad 

Output  Ottt 


PAZ 

Fixpoint  body  uimuth  angle 

rad 

PAZLL 

- 

Fixpoint  locally  level  r/imuth  angle 

nd 

PEL 

- 

Fixpoint  body  elevatic  angle 

nd 

PELLL 

- 

Fixpoint  locally  level  alavation  angle 

nd 

RFIX 

- 

Range  to  fixpoint 

ft 

TAZ 

- 

Target  body  azimuth  angle 

nd 

TAZLL 

- 

Target  locally  level  azimuth  angle 

nd 

TEL 

- 

Target  body  elevation  angle 

nd 

TELLL 

- 

Target  locally  level  elevation  angle 

rad 

TRANCE 

- 

Range  to  target 

ft 

XFIX 

- 

Fixpoint  body  X-coord. 

ft 

XFIXLL 

- 

Fixpoint  locally  level  X-coord. 

ft 

XTARG 

- 

Target  body  X-coord. 

ft 

XTARLL 

- 

Target  locally  laval  X-coord. 

ft 

YFIX 

- 

Fixpoint  body  Y-coord. 

ft 

YFIXLL 

- 

Fixpoint  locally  laval  Y-coord. 

ft 

YTARG 

- 

Target  body  Y-coord. 

ft 

YTARLL 

- 

Target  locally  laval  Y-coord. 

ft 

ZFIX 

- 

Fixpoint  body  Z-coord. 

ft 

ZFIXLL 

- 

Fixpoint  locally  laval  Z-coord. 

ft 

ZTARG 

- 

Target  body  Z-coord. 

ft 

HARLL 

- 

Target  locally  laval  Z-coord. 

ft 

1 
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2.6.2.12  Weather  (WEA1) 


The  weather  model  shall  compute  the  lengths  of  the  line-of -sight  segments  through  each 
of  three  weather  layers  for  all  defined  targets  and  fix  points.  The  model  assumes  three  layers 
of  definable  height  and  thickness. 

The  test  engineer  shall  specify  the  tliickness  of  each  layer  before  the  real-time  simulation 
begins.  The  layers  are  concentric  with  the  earth  sphere  and  are  uniform  over  the  earth’s 
surface.  The  conditions  inside  each  layer  (attenuation  and  scattering  coefficients  at  various 
wavelengths,  rainfall  rates,  etc.)  are  specified  during  set  up;  WEA  1 does  not  deal  with  these 
conditions  and  addresses  only  the  geometry  involved.  Procedure  WEAITT  is  used  to 
initialize  this  weather  model. 

Figure  2.6.2.12-1  is  an  Input/Output  Block  Diagram  of  WEAl  with  the  source  of  each 
input  listed  on  the  left  while  the  disposition  of  each  output  is  listed  on  the  right.  Additional 
Input/Output  nomenclature  definition  is  contained  in  Table  2.6.2.12-1  below. 

2.6.2.13  Atmosphere  Simulation  Model  (ATM2) 

The  objective  of  the  model  ATM2  is  to  simulate  atmospheric  conditions  that  affect  the 
flight  of  the  F-16  aircraft,  such  as  temperature,  pressure,  and  wind. 

ATM  2 is  designed  to  compute  air  temperature,  pressure  density  and  speed  of  sound  ns  a 
function  of  altitude  above  sea  level  for  use  in  the  Airframe,  Air  Data  Computer,  and  sensor 
models.  All  inputs  are  provided  by  the  Reference  model  for  INS  control.  Airplane  altitude 
can  vary  from  sea  level  to  80,000  feet  in  the  atmospheric  model.  The  temperature  is 
calculated  from  temperature-altitude  data  represented  by  linear  line  segments  and  the  alti- 
tude of  interest  that  determines  which  segment  is  being  operated  on.  The  temperature  is  a 
model  output  and  also  an  input  to  the  calculation  for  the  speed  of  sound. 

Figure  2.6.2.13-1  is  an  Input/Output  block  diagram  of  ATM2  with  the  source  of  each 
input  listed  on  the  left  while  the  disposition  of  each  output  is  listed  on  the  right.  Additional 
Input/Output  nomenclature  definition  is  contained  in  Table  2.6.2.13-1  below. 

2.6.2.14  Reference  Model  for  Inertial  Navigation  System  (RMIN) 

The  Reference  model  for  Inertial  Navigation  System  Control  (RMIN)  provides  true  or 
reference  values  of  inertial  acceleration,  velocity  and  position  (latitude  and  longitude)  for 
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use  throughout  the  simulation.  Outputs  of  RMIN  are  accepted  as  those  of  a wander  angle 
mechanized  inertial  navigator  operating  with  no  errors.  These  reference  values  are  used  as 
inputs  by  sensor  models  and  are  corrupted  to  provide  indicated  or  sensed  values.  Principal 
inputs  to  RMIN  are  body  axis  linear  accelerations,  velocities,  angular  rates  (referenced  to  a 
flat,  nonrotating  earth  reference  frame),  direction  cosines,  and  quaternion  parameters  from 
the  Airframe  model. 

Initialization  of  RMIN  is  important  and  is  accomplished  by  a separate  routine,  RMININ, 
before  real-time  execution  begins.  Figure  2.6.2.14-1  is  an  Input/Output  Block  Diagram  of 
RMIN  with  the  source  of  each  input  listed  on  the  left  while  the  disposition  of  each  output  is 
listed  on  the  right.  Additional  Input/Output  nomenclature  definition  is  contained  in  Table 
2.6.2.14-1  below. 

2.6.2.15  Inertial  Reference  Unit  (IRU) 

The  purpose  of  the  IRU  model  is  to  simulate  the  outputs  of  the  Inertial  Reference  Unit 
sensor  components  which  are  triads  of  accelerometers  and  gyros,  with  sensitive  axes 
properly  oriented,  and  mounted  on  a gimballed  platform.  The  Inertial  Reference  Unit  is  the 
primary  source  of  data  for  navigation  of  the  aircraft.  The  accelerometers  provide  data  from 
which  velocity  and  position  are  determined  while  the  gimbals  provide  altitude  information. 
The  gyros,  together  with  their  torquing  system,  aid  in  keeping  the  platform  locallv  level 
when  precession  occurs.  Navigation  information  is  processed  from  IRU  sensors  onboard  the 
aircraft  using  a computerized  navigation  mechanization  called  an  Operational  Flight  Pro- 
gram (OFP). 

The  IRU  model  simulates  accelerations  from  the  platform  accelerometers  and  attitude 
angles  from  the  platform  gimbals.  The  IRU  model  takes  as  inputs  true  attitude  from  the 
airframe  and  locally  level  components  of  inertial  acceleration  from  RMIN,  and  corrupts 
these  true  values  with  gyro  and  accelerometer  (component)  errors.  IRU  component  error 
source  parameters  and  platform  tilts  must  be  initialized.  The  outputs  of  the  IRU  model  are 
indicated  (simulated)  platform  accelerations  and  gimbal  (attitude)  angles  for  use  by  the 
Navigation  OFP.  The  IRU  model  can  be  altered  to  accommodate  a strapdown  inertial 
reference  unit  (SIRU)  during  the  growth  phase.  In  a strapdovra  system,  the  gyros  and 
accelerometers  are  rigidly  mounted  to  the  aircraft  body  axes  instead  of  a gimballed 
platform.  Inputs  to  the  SIRU  model  would  then  require  body  axis  angular  rates  and  body 
axis  linear  accelerations  instead  of  attitude  and  inertial  accelerations  referenced  to  a locally 
level  coordinate  system. 
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RMIN  (Initializption) 

COMMON  DATA 

VXE,  VYE,  VZ.  C. 

VG.  ALAT.  ALONG 

CB.  WEI,  TWOAE, 

CE.  RPPX.  RPPY, 

WEA1 

RM.  PX,  PY.  ERX, 

ERY.  ERZ,  DEG 

REFERENCE 

MODEL 

H 

FOR 

ACGY 

INTERNAL 

G 

NAVIGATION 

FCS 

SYSTEM 

PSIGT.  H 

AFM1 

DIR 

WA.  H.  G 

* 

DT 

RMIN 

ATM2 

AFM1 

G.  H.  RM.  RPPX. 

RPPY 

UDOT,  VDOT,  WDOT, 
SAVED.  SAVEV, 
SAVEW.  SAVEP, 

RALT 

H 

SAVED.  SAVER. 

THETA.  PHI.  PSI. 

ARS 

cQSU.  elSU.  cmU. 

E3SQ.  TEOE1,  TEOE2. 
TEOE3.TE1E2. 

H 

TE1E3.TE2E3. 
A11.A12.  A13. 
A23.A33 

REGE 

1 

■ 

C8.  C.  PX.  PY.  VXE. 

VYE.  VZ.  RM.  RPPX. 

RPPY 

■ 

P 

IRU 

1 

■ 

AXL.  AYL.  AZL. 

WX.  WY.  WZ. 

G 

Fifurt  2.6.2.14-1.  RMIN  input/output  block  ditgrim. 
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TABLE  2.6.2.14-1.  RMIN  INPUT/OUTPUT  NOMENCLATURE 


Input  Data 

FORTRAN  Nama 

Math  Symbol 

Oascription 

Units 

All 

*11 

Direction  cosine  matrix  element 

A12 

*12 

Direction  cosine  matrix  element 

A13 

*13 

Direction  cosine  matrix  element 

A23 

*23 

Direction  cosine  matrix  element 

A33 

*33, 

Direction  cosine  matrix  element 

EOSQ 

Eq  squared 

EISQ 

<E,> 

<E2>5 

E^  squared 

E2  squared 

E2SQ 

E3SQ 

<E3' 

Ej  squared 

PHI 

0 

Airplane  roll  angle 

rad 

PSI 

0 

Airplane  yaw  angle 

rad 

SAVEP 

P 

Body  axis  roll  rate 

rad/$ 

SAVED 

q 

Body  axis  pitch  rate 

rad/s 

SAVER 

r 

Body  axis  yaw  rate 

rad/s 

SAVEU 

u 

X axis  airplane  velocity  WRT  earth 

ft/s 

SAVEV 

V 

Y axis  airplane  velocity  WRT  earth 

ft/s 

SAVEW 

w 

Z axis  airplane  velocity  WRT  earth 

ft/s 

TE0E1 

- 

Two  X EO  X Et  (quaternion  parameter) 

TE0E2 

- 

Two  X EO  X E2  (quaternion  parameter) 

TE0E3 

- 

Two  X EO  X E3  (quaternion  parameter) 

TE1E2 

- 

Two  X El  X E2  (quaternion  parameter) 

TE1E3 

- 

Two  X El  X E3  (quaternion  parameter) 

TE2E3 

- 

Two  X E2  X E3  (quaternion  parameter) 

THETA 

e 

Airplane  pitch  angle 

rad 

UDOT 

u 

X axis  airplane  acceleration  with  respect  to  earth 

ft/s^ 

VDOT 

V 

Y axis  airplane  acceleration  with  respect  to  earth 

WDOT 

w 

Z axis  airplane  acceleration  with  respect  to  earth 

ft/s^ 

Output  Data 

ALAT 

y 

Present  position  latitude 

degree 

ALONG 

\ 

Present  position  longitude 

degree 

AXL 

Axl 

X locally  level  acceleration 

»t/»5 

AYL 

Ayl 

Y locally  level  acceleration 

AZL 

^ZL 

Z locally  level  acceleration 

ft/s^ 

C 

CB 

G 

C^. 

‘'®ll 

g 

Locally  leval-to-earth  direction  cosine  matrix 
Body-to-locally  level  direction  cosine  matrix 

Earth  gravity 

ft/s^ 

H 

h 

Airplane  aKKuda 

ft 

PSIDR 

"I'D 

Drift  angle 

degree 

PSIGT 

YG 

Ground  track  angle 

degree 

PX 

Px 

Vahicla  rata,  X axis 

nilt 

PY 

Py 

Vehicle  rate,  Y axis 

rad/s 

RM 

Range  to  present  position  Z axis 

ft 

RPPX 

R 

"ppx 

Range  to  present  position  X axis 

ft 
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TABLE  2.6.2.14-1.  RMIN  INPUT/OUTPUT  NOMENCLATURE  (con.) 


Output  Data  (con.) 

FORTRAN  Nama 

Math  Symbol 

Oatcription 

Units 

RPPY 

^PPV 

Range  to  present  position  Y axis 

ft 

VG 

^py 

Ground  spaed 

ft/s 

VXE 

Vxe 

X axis  velocity  with  respect  to  earth 

ft/s 

VYE 

''ye 

Y axis  velocity  with  respect  to  earth 

ft/s 

VZ 

Z axis  velocity  with  respect  to  earth 

ft/s 

WA 

Wander  angle 

degree 

WX 

w 

X axis  angular  rate 

rad/s 

WY 

A 

LJ 

Y axis  angular  rate 

red/s 

WZ 

U> 

^2 

Z axis  angular  rate 

red/s 

IRU  component  error  source  models  are  statistical  in  nature,  with  the  range  of  inputs 
being  large  enough  to  model  a variety  of  IRUs.  All  modeled  error  sources  accept  outputs 
from  a random  noise  generator  subroutine  which  produces  normally  distributed  noise  that  is 
dependent  on  a user-specified  mean  and  standard  deviations.  All  modeled  IRU  error  sources 
are  normally  included  in  each  iteration  and  run;  however,  the  user  can  delete  any  error 
source  variable. 

Figure  2.6.2.15-1  attempts  to  show  the  interaction  of  this  model  with  other  elements  of 
the  real-time  model  set.  The  source  model  of  each  input  is  listed  on  the  left  while  the 
disposition  model  is  listed  on  the  right.  Additional  nomenclature  definition  is  contained  in 
Table  2.6.2.15-1  below. 


2.6.2.16  Flux  Valve  Model  (FLUX) 

The  Flux  Valve  sensor  (one  of  the  navigation  models)  provides  a source  of  magnetic 
heading;  that  is,  if  the  magnetic  variation  corresponding  to  the  present  aircraft  position 
\ relative  to  the  earth  is  known,  true  north  can  be  approximately  determined  by  using  a flux 

valve  output.  A typical  flux  valve  output  is  a noisy  analog  signal,  which  is  smoothed  by 
using  the  AFRS  directional  gyroscope. 

I 

I The  flux  valve  model,  FLUX,  simulates  a source  of  magnetic  heading  which  can  be  used 

^ for  navigation.  As  shown  in  the  Input/Output  Block  Diagram  of  Figure  2.6.2.16-1,  FLUX 

receives  inputs  of  true  heading  from  AFMl,  magnetic  variation,  and  flux  valve  noise 
standard  deviation  from  the  user  initialization  to  produce  flux  valve  magnetic  heading. 


I 

j 
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TABLE  2.6.2.1S-1.  IRU  INPUT/OUTPUT  NOMENCLATURE 


FORTRAN  Nam*  MMh  Symbol 

AXL  Ay. 

AYL  Ayl 

A2L  A^l 

G g 

PHI  0 

PSIP  *p 

THETA  9 

WX 
WY 

WZ  w. 


Input  Oita 
Oascription 

X locally  lavol  acceleration 

Y locally  level  acceleration 
Z locally  lavel  accaleration 
Earth  gravity 

Airplane  roll  angle 

Airplane  yaw  angle  plus  wander  angle 
Airplane  pitch  angle 
X exit  anguler  rate  (LL/I) 

Y axis  angular  rate  (LL/I) 
Zaxisengular  rate  (LL/I) 

Output  Data 

Platform  acceleration,  X axis 
Platform  acceleration,  Y axis 
Platform  acceleretion,  Z axis 
Indicated  roll  angle 
Indicated  azimuth  angle 
Indicated  pitch  angle 


TABLE  2.6.2.1B-1.  FLUX  INPUT/OUTPUT  NOMENCLATURE 


FORTRAN  Name  Math  Symbol 

PSI  * 

PSIMV 

SIGMV 


Input  Data 

Description 

True  heading 
Magnetic  variation 
Noise  standard  deviation 

Output  Data 

Flux  valve  indicated  magnetic  heading 


’ User  input  for  initialization  only. 
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wliitii  is  rouloil  to  tho  navigation  inotlel  NAV,  'I’lio  souroo  nicKlol  of  oach  input  is  listoii  on 
tlu'  loft  whilo  tho  disposition  modol  is  listed  on  the  rinlit.  Adtlitional  nomenolaturo 
definition  is  eontaiiUHl  in  'I'able  2. G. 2. 16-1  below. 
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2.7  PROCESSOR  ARCHITECTURE  (ISP) 

The  Processor  Architecture  (ISP)  simulation  facility  enables  a user  to  describe  computer 
processing  units  at  the  register  transfer  level,  and  from  these  descriptions  to  quickly  set  up 
interactive  simulations  of  these  processors.  A language,  CSL/ISP  (Computer  Simulation 
language,  a dialect  of  Instruction  Set  Processor  language),  was  developeil  as  a .liaUvt  of  ISPI, 
from  Carnegie-Mellon  University.  A compiler  prcxluces  PDP-10  code  f'om  the  CSL/ISP 
source  and  the  user  then  runs  this  code  from  a control  program  which  he  constructs  by 
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modifying  a model,  general  purpose  simulation  control  program.  A methodology  is  included 
for  creating  simulations  from  manufacturers’  instruction  set  descriptions. 

From  a description  of  the  register  transfers  of  a computer,  the  processor  simulation 
program  can  produce  a simulation  of  that  computer.  This  program  may  he  broken  into  three 
general  areas.  These  include  a formal  language  compiler  with  which  to  descril)e  register 
transfer  level  processes,  a code  generator  to  produce  DEC-10  code  from  the  output  of  a 
compiler  for  that  language,  and  a general  purpose  control  program  with  which  to  drive  the 
simulators  produced  from  the  compiler. 

The  compiler  uses  a set  of  register  transfer  operators,  called  XT-op’s,  to  produce  a set  of 
pseudo  instructions  which  can  be  interpreted  by  the  DEC-10  assembler’s  (MACRO)  facility. 
The  macros  which  were  written  to  produce  DEC-10  code  from  these  pseudo  instructions 
produce  optimized  code,  and  they  comprise  a universal  library  which  is  searched  during 
assembly. 

Simulations  are  controlled  by  a program  with  which  the  user  can  interactively  set 
registers  and  memory  locations,  load  memory,  set  breakpoints,  etc.  The  control  program 
causes  instructions  in  simulated  memory  to  be  executed  by  repetitively  calling  on  the 
simulator  to  execute  a single  instruction. 

The  behavior  of  a processor  is  determined  by  the  nature  of  its  individual  operations  and 
the  sequence  in  which  those  operations  occur.  This  sequence  is  generally  governed  by  a 
stored  program,  which  resides  in  the  memory  of  the  computer  and  the  set  of  interpretation 
rules  which  the  processor  applies  to  the  program. 

Although  the  above  format  is  commonly  used  to  describe  digital  computers.  ISP  does 
not  limit  the  user  to  a particular  type  of  description.  Thus,  ISP  can  be  used  to  describe 
register  transfer  systems  in  general;  digital  computers  are  a subset  of  such  systems  which 
interpret  an  instruction  set.  Other  devices,  such  as  busses  and  device  controllers,  can  also  be 
described  in  ISP. 

2.7.1  Specific  Simulations 

Three  simulations  were  developed  as  test  cases  for  this  project  and  are  present «1  in  this 
section.  They  are  the  INTEL  8080  microprocessor,  the  PDP-8  minicomputer,  and  the  DAIS 
-oionics  processor.  The  three  simulations  differ  greatly  in  complexity,  ranging  from  the 
simple  PDP-8  to  the  quite  complicated  DAIS  processor.  The  general  process  showing  how  to 
use  the  CSL/ISP  system  to  produce  and  run  a simulation  is  shown  in  Figure  1.7. 1-1. 
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2.7. 1.1  The  PDP-8  Simulation 


The  PDP-8  simulation  was  undertaken  because  of  the  simplicity  of  its  instruction  set  (it 
has  six  memory  reference  instructions  and  two  micro  instructions)  and  because  of  its  wide 
range  of  users.  These  reasons  make  it  a useful  demonstration  example  for  the  full  use  of  the 
simulation  facility,  from  the  CSL/ISP  description  to  the  simulation  itself. 

The  processor  description  includes  the  fetch  cycle,  the  memory  reference  instructions 
and  one  micro  instruction.  The  input/output  micro  instruction  was  not  described.  Some 
simple  programs  were  loaded  (from  the  output  of  the  P.ALIO  assembler)  and  run.  The 
PDP-10  to  PDP-8  runtime  ratio  was  about  90  to  1,  well  within  the  range  of  acceptable 
simulation  times. 

2.7. 1.2  The  INTEL  8080  Simulation 

The  development  of  a simulation  module  for  the  INTEL  8080  microprocessor  through  a 
CSL/ISP  description  was  undertaken  for  two  reasons.  First  of  all,  it  was  written  in  order  to 
check  operations  with  a laiige  description  (>200  instruction  routines).  Secondly,  it  was  used 
to  help  test  and  debug  the  CSL/ISP  compiler  and  the  simulation  control  strategy’.  This 
second  reason  was  particularly  strong  since  a simulator  of  the  INTEL  8080  was  already 
available  and  results  could  be  compared. 

The  simulator  adheres  to  the  description  of  the  processor  found  in  the  INTEL  8080 
manual  (INT74)  with  three  exceptions. 

1.  The  undefined  operation  codes  are  trapped  by  the  simulator  as  errors.  The  manual 
does  not  define  the  action  of  the  processor  for  these  operation  codes. 

2.  One  of  the  undefined  operation  codes  was  utilized  as  a break  trap  instruction.  The 
operation  code  used  is  20  octal. 

3.  All  input  and  output  for  any  channel  is  directed  to  the  terminal. 


The  execution  speed  of  the  simulation  was  timed  and  found  to  be  100  to  1 compared  to 
actual  execution  speed. 

2.7. 1.3  The  DAIS  Processor  Simulation 

This  is  the  largest  simulation  implemented  in  ISP.  The  instruction  set  of  the  DAIS 
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processor,  built  for  the  Air  Force  by  Westinghouse  Electric  Corporation,  was  described  with 
CSL  and  subsequently  simulated.  Neither  the  bus  control  equipment  nor  the  direct  memory 
access  eqipment  was  simulated. 

The  simulation  extends  beyond  the  machine  described  in  the  manual  in  two  ways. 

First,  the  interrupt  system  is  modeled  as  described  in  the  manual.  However,  the 
simulator  will  respond  by  calling  a routine  within  the  control  program  if  any  of  the 
conditions  for  which  interrupt  responses  are  included  occur  when  interrupts  are  disabled. 
Thus,  the  user  can  either  elect  to  include  code  in  his  programs  to  detect  interrupt 
conditions,  or  he  may  rely  on  the  simulator/control  program  to  inform  him  when  these 
conditions  occur.  The  following  interrupt  situations  are  handled  by  the  simulator: 


1.  Illegal  operation  code  (external  routine  OPERATION), 

2.  Boundary  alignment  error  (external  routine  BOUNDARY), 

3.  Interval  timer  “A”  interrupt  (external  routine  TIMERA), 

4.  Interval  timer  “B”  interrupt  (external  routine  TIMEB),  and 

5.  Processor  memory  protect  (external  routine  PROTECTION). 

Second,  a branch  trace  facility  was  added  to  the  simulation  package.  Any  branch  which 
alters  the  instruction  counter  (1C)  is  recorded  in  a 32-word  table  by  the  REMEMBER 
routine  of  the  control  array.  The  contents  of  the  control  array  (J. ADDRESS)  can  be 
inspected  by  using  SIX12;  index  word,  J.INDEX,  points  to  the  next  word  of  the  array  to  be 
used.  Entries  are  made  in  J.ADDRESS  in  cyclic  fashion.  Thus,  the  entry  in  the  word 
indicated  by  the  contents  of  J.INDEX  is  the  first  of  the  entries  in  the  array  to  have  been 
made.  Each  word  of  J.ADDRESS  holds  the  location  of  the  jump  instruction  in  the  upper 
half  word,  and  the  destination  of  the  jump  in  the  lower  half  word.  The  SIX12  typeout 
format  types  these  values  in  the  form  UPPER,  LOWER  at  the  extreme  right  end  of  the  line 
for  each  value  typed. 

Several  instructions  are  simulated  primarily  by  means  of  external  routines  written  in 
DEC  MACRO  assembly  language.  All  of  this  external  code  is  included  in  two  external 
modules.  The  two  modules  and  the  routines  included  in  them  are  as  follows: 

1.  Module  FLOAT,  source  file  FLOAT.MAC,  relocatable  fUe  FLOAT,  REL  includes 
entry  points: 

a.  FA:  floating  add, 

b.  FS:  floating  su bract. 
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c.  FNEG:  floating  negate, 

d.  FABS:  floating  absolute  value, 

e.  FC:  floating  compare, 

f.  FM;  floating  multiply, 

g.  FD:  floating  divide; 

2.  Module  FIXED,  source  file  FIXED. MAC,  relocatable  file  FIXED. REL  includes  the 

entry  points: 

a.  MPY64:  fixed  point  double  precision  multiplication, 

b.  DIV64:  fixed  point  double  precision  division. 

The  simulator  executes  one  instruction  for  each  call  by  the  control  program.  The  first 
step  in  an  instruction  execution  is  to  look  for  and  to  respond  to  any  interrupts  that  may  be 
pending  if,  and  only  if,  interrupts  are  enabled.  Following  this,  the  simulator  fetches  the  next 
instruction  into  the  pair  of  instruction  registers  IRO  and  IRl.  The  bulk  of  the  simulator 
performs  instruction  decoding,  which  begins  after  the  instruction  fetch  is  complete.  The 
decoding  consists  of  a 16-way  decode  of  the  high  order  operation  code  digit;  each  of  the  16 
elements  in  the  range  of  this  DECODE  is  a 16-way  DECODE  of  the  low  order  operation 
code  digit. 

Each  simulation  for  each  instruction  assumes  that  IRO  contains  the  operation  code 
portion  of  the  instruction,  and  that  IRl  contains  the  address  portion  of  the  instruction  if 
there  is  one. 

2.7.2  The  CSL/ISP  Language 

CSL/ISP  is  a language  for  describing  digital  systems  at  the  register  transfer  level, 
including  descriptions  of  the  computer  memory,  registers,  instruction  set,  interrupt  system 
and  input/output  system.  A program  in  CSL/ISP  consists  of  two  parts,  a description  of  the 
storage  elements  of  the  system,  and  a description  of  how  the  system  operates  on  those 
storage  elements. 

2.7,2. 1 Legal  Characters 

CSL/ISP  input  consists  of  a stream  of  ASCII  seven-bit  characters.  The  characters  which 
the  compiler  accepts  include  the  alphabetic  characters  A - Z and  a - z.  The  compiler  makes 
no  distinction  between  upper  and  lower  case  alphabetic  characters.  In  addition,  the  compiler 

accepts  the  numerals  0-9  and  the  characters  (,] , <,  >,  (,  ),  $,  ?,  #,  ',  %,  !,  \,  +,  -, 

. • (left  arrow,  which  is  an  underline  character  in  some  ASCII  character  sets), .,  CR,  LF, 

TAB,  SPACE,  and,.  All  other  characters  are  illegal. 
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21.2.2  Identifiers 

Identifiers  are  used  as  names  of  various  computer  components  and  as  labels  for 
statements  and  procedure  declarations  in  a description.  An  identifier  begins  with  an 
alphabetic  character  and  is  composed  of  any  number  and  combination  of  alphabetic 
characters  (both  upper  and  lower  case),  numerals  and  the  period,  . Names  must  be 
distinct  in  their  first  six  characters. 

EXAMPLES: 

XI,  xi.  Sixteen,  One.Step,  P296.1. 

The  names  Pistepl  and  PISTEP2  are  recognized  as  the  same  identifier. 

The  compiler  accepts  an  extension  to  an  identifier  which  can  be  used  to  give  more 
information  about  the  symbol.  The  compiler  treats  the  added  information  as  a comment. 
The  syntax  for  this  type  of  comment  is: 

identifier/string  of  characters  valid  in  an  identifier 

The  “V’  need  not  be  preceded  by  an  identifier,  and  all  valid  identifier  characters  which 
follow  the  “\”  are  ignored  until  a separator  character  is  found.  Thus,  this  construction  can 
be  used  to  insert  comments  into  the  middle  of  a line. 

EXAMPLES: 

XTHIS.IS.A.COMMENT 

\1  ! THIS  IS  A COMMENT  TOO 

SW.CONXCONSOLE.SWITCHES 

Further  examples  are  given  in  a later  section. 

2.7.2.3  Numbers 

Numbers  may  appear  in  the  input  in  binary,  octal,  decimal  or  hexadecimal  form.  Special 
prefbc  characters  indicate  the  base  of  the  number  which  the  subsequent  numerals  designate. 
These  prefix  characters  are: 


binary, 


I 
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# octal, 

Digit  decimal, 
% hexadecimal. 


The  compiler  converts  the  input  representation  into  an  internal  binary  number  which 
1 R 

cannot  exceed  2 —1. 

EXAMPLES; 

103  is  103jo 
1101  is  13^0 
#72  is  58jo 
%AF  is  175jq 

1 Q 

The  number  %7FFFF  cannot  be  correctly  compiled  because  it  exceeds  2^°  — 1. 

2.7.2.4  Program  Structure 

CSL/ISP  is  a block  structured  language;  a CSL/ISP  program  is  a labeled  block  which 
starts  with  a BEGIN  and  is  terminated  by  an  END.  A CSL/ISP  block  may  have  a declaration 
section.  A nontrivial  CSL/ISP  program  will  generally  have  a declaration  section  followed  by 
an  action  section.  The  declaration  section  defines  the  elements  upon  which  actions  are 
performed.  The  form  for  a block  is  thus: 

PDP8  :=  BEGIN 

optional  declaration  section 
action  section 
END  . 

2. 7.2. 5 The  Declaration  Section 

The  declaration  section  permits  the  user  to  define  the  storage  elements  of  the  processor, 
namely,  registers  and  memories.  These  storage  declarations  may  represent  the  registers  and 
memories  of  the  computer  being  described,  or  they  may  be  working  storage  for  use  in  the 
simulation.  In  addition,  external  procedures,  internal  procedures,  and  macro  declarations 
can  be  declared  in  the  declaration  section. 

The  declaration  section  occurs  optionally  as  the  first  part  of  a block,  and  is  delimited  by 
the  reserved  words 
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DKCLARK  . . .ERALCED 

(spell  declare  backwards).  The  declarations  within  the  declaration  section  are  separated  by 
semicolons.  Extra  semicolons  may  appear,  and  the  final  declaration  need  not  be  followed  by 
a semicolon. 

2. 7.2. 5.1  Storage  elements 

The  storage  elements  of  a computer  which  can  be  described  in  CSL  ISP  are  registers  and 
memories.  The  general  declaration  form  for  a register  declaration  is 

name  <l)it  range> 

where  name  is  any  identifier,  and  bit  range  is  either  an  empty  field,  a number,  or  a pair  of 
numbers  separated  by  a colon.  Since  the  compiler  generates  a simulator  which  stores  each 
register  and  each  word  of  a memorj’  in  one  DEC-10  word,  register  sizes  may  not  exceed  36 
bits,  which  is  the  size  of  a PDP-10  word. 

.•\  memor>'  is  an  array  of  words  all  of  which  have  the  same  bit  specification.  Its 
declaration  has  the  form 

memory  [word  range]  < hit  range  > 

where  memory  is  an  identifier,  word  range  is  a single  number  or  a pair  of  numbers  separated 
by  a colon,  and  hit  range  is  the  same  as  that  for  registers. 

Other  computer  components  such  as  I/O  ports  and  switch  registers  can  also  be  declared 
as  registers. 

2.7. 2.5.2  External  declarations 

To  permit  a control  program  and  SIX12  (the  BLISS  debugging  system)  to  access  the 
storage  of  a simulated  machine,  memories  and  registers  may  be  declared  within  an  external 
declaration  subsection,  the  form  being 

EXTERNAL  external  declarations  LANRETXE  . 

An  external  subsection  occurs  as  a declaration  in  a declaration  section.  Thus,  it  must  be 
separated  by  semicolons  from  the  other  declarations.  Memories  and  registers  are  declared  in 
the  external  subsection  just  as  they  are  declared  outside  it. 

2.7.2.5.3  Overlay  declarations 

Registers  and  memories  may  be  defined  in  terms  of  other  memories  or  registers  which 
have  been  previously  declared.  This  allows  one  to  define,  for  instance,  the  operation  field  of 
an  instruction  register  as  a register  itself. 
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In  a similar  manner,  overlays  may  be  specified  on  memories.  The  constraints  on  memorj’ 
overlays  are  more  complicated  than  those  on  register  overlays  due  to  the  DEC-10  assignment 
of  arrays.  When  a memory’  is  declared,  its  words  are  assigned  one  word  at  a time  to 
consecutive  DEC-10  words,  so  that,  for  instance,  4,096  twelve-bit  words  are  assigned  to 
4,096  PDP-10  words.  Memory  overlays  must  be  declared  such  that  DEC-10  word  boundary' 
crossings  are  not  implied  by  the  declaration. 

2.7.2.5.4  Procedure  declarations 


Procedures  manipulate  the  contents  of  storage  elements.  Their  declarations  have  one  of 
the  two  forms; 


I 


I 


name  ;=  unlabeled  statement 
name  :=  block 

where  name  is  an  identifier  and  is  the  name  by  which  the  procedure  is  called.  The  statement 
or  block  defines  the  actions  of  the  procedure. 

2.7.2.5.5  Macro  declarations 

The  compiler  has  a macro  facility  which  allows  the  user  to  substitute  strings  of 
characters  for  names  which  occur  in  his  program.  Macros  may  be  declared  with  or  without 
parameters.  A macro  declaration  has  one  of  the  following  two  forms: 

MACRO  name  = string  $ 

MACRO  name  (pl,p2,.  . . pn)  = string  $ 

where  name  is  an  identifier,  pi,.  . . 4m  are  identifiers  which  name  the  parameters,  and  string 
is  a string  of  characters  which  includes  any  character  but  the  dollar  sign,  “S". 

2.7.2.6  The  Action  Section 

The  action  section  consists  of  a group  of  parallel  actions  which  are  separated  by  the 
reserved  word  NEXT.  A parallel  action  is  a group  of  statements  separated  by  semicolons. 
The  interpretations  of  the  sequence 


statement  1 ; statement  2 ; statement  3 
NEXT 


347 


statement  4 ; statement  5 

NEXT 

statement  6 


is  that  statement  1,  statement  2,  and  statement  3 are  performed  simultaneously.  After  their 
completion,  statement  4 and  statement  5 are  performed.  Finally,  statement  6 is  performed. 

The  semantic  distinction  lietween  statements  grouped  for  parallel  execution  and 
sequences  of  such  groups  has  lieen  reduced  to  a syntactic  distinction  in  CSL/ISP.  In  a 
simulator  produced  by  CSL/ISP,  statements,  whether  separated  by  semicolons  or  NEXT 
reserved  words,  are  executed  sequentially. 

The  statements  which  can  appetu  in  the  action  section  are  of  several  types.  Included 
among  these  elements  are  register  transfer  statements,  conditional  branching  statements, 
jumps,  procedure  calls,  return  statements,  and  blocks. 


2.7. 2.6.1  Assignment  statements 


lYansfers  of  data  between  storage  elements  are  represented  by  assignment  statements. 
The  generiil  form  of  an  assignment  statement  is 

target  <-  computation 

where  target  is  a set  of  contiguous  bits  in  a storage  element  which  is  to  receive  the  result  of 
the  computation  indicated  on  the  right  side  of  the  The  computation  is  either  an 

arithmetic  or  logical  operation  on  bits  of  storage  elements,  or  it  is  simply  a reference  to  bits 
from  a storage  element.  .Any  bit  or  contiguous  group  of  bits  in  a register  or  memory  word 
may  be  accessed  for  the  reading  or  writing  of  information. 

2.7.2.6.2  Operators 


Data  in  storage  elements  may  be  modified  as  a result  of  various  unary  and  binary 
operations  on  data  in  other  storage  elements.  These  operators  are: 

shift  o^^erators  The  value  of  the  expression  is  shifted. 


NOT 

AND  EQV 
OR  XOR 
unary  + and  — 
* / MOD 


Logical  operators  including  the  logical  complement  NOT, 
Unary  operators. 

Binary  ojx^rators. 
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2.7.2.6.3  Nested  expressions 

The  normal  precedence  for  the  operators  may  be  altered  by  enclosing  subexpressions  in 
parentheses.  Because  CSL/ISP  is  intended  for  use  in  describing  the  actions  of  digital  devices. 

j the  default  operator  precedence  may  differ  from  that  in  the  normal  higher  level  language 

such  as  FORTRAN. 

2.7.2.6.4  Conditional  statements 

There  are  two  different  conditional  statements  in  the  CSL/ISP  language,  namely,  the  IF 
statement  and  the  DECODE  statement.  Each  of  these  statements  makes  use  of  a rtdational 
expression.  The  syntax  and  semantics  of  relational  expressions  lU’e  discussed  in  the  following 
section.  That  section  is  followed  by  two  sections  which  discuss  the  IF  and  DECODE 
statements. 

I 2.7.2.6.5  Relational  expressions 

I 

1 .A  relational  expression  has  one  of  the  two  following  forms: 

I X relational  operator  Y. 

X. 

’ Both  .X  and  Y in  the  above  forms  can  be  arbitrar>’  expressions  involving  shift,  logical,  and 

arithmetic  operators.  The  relational  operators  are: 

LSS  less  than. 

LEQ  less  than  or  equal  to. 

EQL  equal. 

NEQ  not  equal. 

GTR  greater  than. 

GEQ  greater  than  or  equal  to. 

2.7.2.6.6  The  I F statement 

The  IF  statement  provides  for  conditional  execution  of  any  CSL/ISP  action  section.  The 
form  of  the  IF  statement  is 

If  relational  expression  = > action  section  ? . 

The  low  order  bit  of  the  relational  expression  determines  whether  the  action  section 
which  follows  the  “=>”  is  executed. 

, 349 

i: 

I 


2. 7. 2.6.7  The  DECODE  statement 


The  DECODE  statement  selects  one  statement  from  a list  of  statements  for  execution. 
The  form  of  the  DECODE  statement  is 

DECODE  relational  expression  = > statement  list  ? . 

The  value  of  the  relational  expression  serves  as  an  index  value  to  determine  which  one  of 
the  statements  in  the  statement  list  is  executed. 

2.7.2.6.8  Flow  of  control  statements 

The  flow  of  control  in  a CSL/ISP  program  is  sequential.  Statements  are  executed  in  the 
order  written,  even  if  separated  by  semicolons  to  imply  parallel  execution.  The  flow  of 
control  can  be  modified  by  three  different  statements; 

1.  Jump— jump  to  statement  labeled  by  identifier, 

2.  Procedure-call  statement,  and 

3.  RETURN-retum  to  point  of  call. 

2.7.2.6.9  Blocks 

A statement  can  also  be  a block.  A frequent  use  of  a block  is  to  include  an  extensive 
action  section  as  one  alternative  in  the  scope  of  a DECODE  statement.  A block  includes  an 
optional  declaration  section  followed  by  an  action  section,  and  therefore  has  the  form: 

BEGIN 

Optional  declaration  section 

Action  section 

End 

The  part  of  the  program  in  which  a declaration  holds  is  governed  by  the  block  in  which  it  is 
declared. 

2.7.2.6.10  Macro  calls 

A CSL  macro  can  be  declared  with  or  without  parameters.  A macro  declared  with  no 
p>arameters  must  be  called  with  no  parameters;  a macro  declared  with  parameters  must  be 
called  with  parameters.  A macro  is  called  by  using  its  name.  Parameters  follow  the  name, 
enclosed  in  parentheses.  The  parameters  are  septarated  by  commas.  Extra  parameters  in  a call 
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aro  innoml.  and  missing  parainoloi's  an'  n'plarotl  by  tlu'  null  siring*  in  tho  I'xpansion  pronoss. 
A inaon>  iloolan'tl  with  paranu'U'rs  must  bo  oallinl  by 

naino  ( ) 

to  uso  thi'  null  string;  for  all  parainolors.  Rooiu'sivo  maoro  oalls,  iuoludin^  loops,  an-  not 
allowt'd.  Tbo  oomi'ilor  dotoots  an  attoinpt  tii  uso  maoros  rooursivi'ly  and  roports  tbo  namo 
(or  nanu's  if  a loop  is  involvt'tl)  of  tbo  offondinn  nuicro(s)  in  tbo  orror  inossa^o. 

2. 7. 2. 7 The  Control  Program 

.■\  simplo  oontrol  iiro^ram  slunilu  roly  on  tbo  SIX  12  dobu^;^:in^;  |'aoka^;o  of  tbo  HLISS 
systom  f('r  many  of  tlu'  faoilitii's  wbioli  it  I'rovidos  to  a usor.  SIX  12  oaii  intoraot  with  tbo 
usi'r  to  dist'lay  and  alter  the  values  of  global  and  own  variables  of  BLISS  and  M.kCIU' 
lirograms.  Tluis.  SIX  12  oan  l>o  used  to  insi>oot  memory  and  rogistt'r  oiuitonts  of  a simulalod 
maobino,  alter  those  valiu's  wbon  lU'oossary.  and  in  general,  oontrol  both  tbo  debugging  and 
use  of  a simulator.  Tbo  normal  funetions  of  a sinn'U'  oontrol  jirogram  are: 

1.  ('all  a loader  module  whieb  is  written  siu'eifiealiy  for  that  simulator;  tbo  loader  is 
written  to  b<'  able  to  read  a file  |>re('ared  by  a eross-assembler  linking-loader  system 
whieb  produees  a program  file  for  tin*  simulated  eomputer;  the  (irogram  file  minit 
often  ineludes  a starting  address  for  exeeiition.  so  tbat  the  loailer  will  often  set  the 
mstruetion  eounti-r  of  the  simulator  as  well  as  loading  eode  into  its  memoiy. 

2.  Make  periodie  ealls  on  SIX  1 2 so  tbat  the  user  ean  oontrol  the  simulation  }>roee.ss, 

2.7. 2.8  The  Register  Transfer  Operations 

The  register  transfer  operations  whieh  oeeur  in  the  '^ininit  file  name'''.M At' outi'ut  file 
of  the  ('SL/ISP  ei'inpiler  and  whieb  define  the  exeeutable  eode  of  the  simulation  moil’ile  are 
known  as  XT-oiierations  within  the  eompiler.  In  the  ---.ininit  FILK  name^.M.At'  file  the 
general  form  for  an  XT-o(ieration  maero  eall  is 

oiieration  (SlU'l.  SU('2.  UKST) 

win're  SUt'l  ami  SH('2  are  the  .soiirees  for  the  operation,  and  ItKST  is  the  destination  for 
the  result  of  the  operation  involving  SUt'l  and  SKt"2.  In  some  eases,  the  operands  are 
optional  or  lake  sp«>»'ial  forms. 

7 7 3 PrcKessor  Simulation 

2 7 3 1 Thff  Computer  Simulation  Language  Compiler 

111.  t'ompuii'r  Simulation  Language  (t'SL)  eonunler  is  written  in  the  HilSS 
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unpU'inenfation  lattguaf{<’  (or  liu'  DKC’  H).  I'Im'  lonipiler  is  or^anizini  into  seven  BLISS 
modules.  In  each  module,  there  is  one  primur>’  routine  and  a collection  of  support int; 
routines  The  followin^;  table  ^ives  an  overview  of  the  compiler  ornanization. 


Modul* 

Mmary  RMtkMtd 

ftimapf  Feiiction 

CSGBL 

nuin  body 

Compiltr  initiilization  and 
global  daclarationt 

eSPRS 

PRSE 

Laxically  analyia  and  pana 
tha  lourca  program 

CSMAC 

0EFMACR0& 

Accapt  and  axpand  macro 

EXPMACRO 

dafinitions 

CSSEM 

SEMANTICS 

Partorm  coda  ganaration 
and  tamantic  actions  corra- 
tponding  to  terminal 
symbols 

CSGEN 

GENERATE 

Perform  code  generation 
and  semantic  actions  corre- 
sponding to  syntactic 
reductions  during  parsing 

CSOPT 

OPTIM 

Reorder  the  code  and  opti- 
mile  tha  flow  of  control 

CSOUT 

OUTTABLES 

Write  out  SYTABLE  and 
STTABLE  for  later  assembly 

The  t'SL  comiuiter  is  a two  imsn  ooiupilor.  Durinj;  the  first  pass,  compiler  modules 
eSPRS,  t'SMAC,  (’St'iKN,  aiul  ('SSKM  cooperate  to  parse  the  .source  projjram  and  translate 
it  into  an  encoded  version  of  the  eventual  output  in  the  statement  table,  S'lTABLK.  During 
the  second  pa.ss,  compiU-r  module  ('SOl’T  rt'orders  the  code  in  STl'.ABLK  aiul  optimizes  the 
flow  of  control.  Finally,  module  t'SOUT  writes  init  tiie  conienis  of  tlie  symbol  table 
(SY’rABLK)  and  the  statement  tal.le  (STTABLK)  for  later  assembly  by  the  UKr  assembler 
M.U'Kt). 

2. 7, 3. 1 , 1 The  syntax  graph 


I’arsinu  is  done  top  ihiwn  and  is  talile  driven  from  a syntax  (traph.  The  uraph  is  reduced 
l>y  factormis  common  strin^;s  of  leaiiinn  symbols  in  a set  of  alternatives  tor  a production. 
Recursive  productions  are  recoK’iiized  for  further  simplification  and  modes  whciv  values  and 
links  arc  identical  arc  eliminated. 
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2.7.3.1.2  The  parser 

riu'  routines  which  parse  CSL  are  in  the  module  CSPRS.  Parsing  is  accomplishetl  by  an 
implementation  of  a nonrecursive  algorithm.  The  algorithm  has  lieen  modified  to  eliminate 
the  pointer  stack  and  to  include  recognition  of  missing  right  hand  delimiters.  The  parsing 
process  dears  with  two  classes  of  objects:  terminal  symbols  and  recognized  productions. 
Terminal  symbols  are  handled  by  the  compiler  module  CSSEM  and  recognized  productions 
are  operated  upon  by  the  compiler  module  CSGEN. 

2.7.3.1.3  The  syntax  analyser 

The  routine  PRSE  performs  the  task  of  parsing  the  CSL  source  and  of  making  calls  to 
the  semantic  routines  SEMANTICS  and  GENERATE  in  order  to  produce  code.  In  order  to 
analyze  the  input,  PRSE  calls  on  the  routine  SCAN  which  fetches  and  analyzes  the  next 
lexical  unit,  or  lexeme,  in  the  input.  It  does  this  by  “sliding”  a “window"  through  the 
source  in  order  to  set  up  the  new  current  lexeme.  In  addition,  this  window  positions  itself 
over  the  last  two  lexemes  analyzed  and  over  the  next  two  lexemes  past  the  current  lexeme. 
New  entries  conceptually  are  entered  into  the  window  from  the  right  and  disappear  from 
the  left.  A new  entry  is  made  when  SCAN  calls  the  routine  GETLEX.  GETLEX  determines 
the  type  of  lexeme  coming  up  either  from  its  first  character  or  from  the  value  of  (he  flag. 
FLAGSTRING,  which  is  set  by  the  .semantics  when  a macro  definition  is  arriving  on  the 
input.  GETLEX  then  calls  IDENT,  NUMBR,  OPERATOR  or  DERMACRO  to  fetch  the 
lexeme  and  set  the  window  entry. 

After  the  window  has  been  advanced,  the  parser  compares  the  value  of  the  current 
lexeme  in  the  window  with  the  value  of  the  current  node  in  the  syntax  graph.  If  they  match 
and  certain  other  conditions  are  satisfied,  the  parser  calls  the  semantic  routines  to  produce 
code.  Otherwise  a new  node  is  selected  and  the  comparisons  continue  until  the  proper  node 
is  located. 

2.7.3.1 .4  Code  generation 

The  code  generation  process  is  controlled  by  the  contents  of  various  stacks,  flags,  and 
other  variables.  The  contents  of  these  control  variables  are  set  by  the  code  generation 
routines  and,  in  turn,  control  the  actions  of  those  routines. 

All  of  the  codes  produced  by  the  compiler  are  generated  by  calls  to  routine  STATE  of 
compiler  module  CSGEN.  Routine  STATE  responds  to  calls  by  placing  an  encoded  from  of 
the  eventual  output  in  the  statement  table,  STTABLE. 
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2.7.3.1.5  Compiler  output 


Except  for  the  listing  file  (<input  file  name>.LST,  produced  by  compiler  module 
CSPRS),  all  output  from  the  CSL  compiler  is  produced  by  compiler  module  CSOUT.  The 
output  consists  of  two  files  when  the  source  file  contains  EXTERNAL  declarations  and  one 
file  when  no  EXTERNAL  declaration  occurs.  Both  output  files  are  intended  to  be 
assembled  by  the  DEC  assembler  MACRO;  there  is  a macro  library  appropriate  to  each 
output  file. 

The  primary  output  file  (<input  file  name>.MAC)  contains  the  internal  storage 
declarations  and  executable  code  for  the  eventual  simulator;  it  should  be  assembled  using 
the  macro  library  CSL. UN V.  The  file  produced  when  EXTERNAL  declarations  occur  is 
<input  file  name>.EXT;  it  contains  storage  allocation  and  ENTRY  definitions  for  the 
EXTERNAL  variables  and  should  be  assembled  using  macro  library  EXT.UNV. 

Compiler  module  CSOUT  writes  both  of  the  above  output  files.  The  variable  EXTRN 
(one  of  the  variables  in  the  control  array  CSVAR)  indicates  when  an  external  file  is 
necessary.  CSOUT  initially  goes  through  the  symbol  table,  SYTABLE,  and  writes  the  file 
<input  file  name>.EXT  and  the  storage  allocation  part  of  file  <input  file  name>.MAC. 
CSOUT  then  goes  through  the  statement  table,  STTABLE,  and  writes  the  executable 
portion  of  the  <input  file  name>.MAC  file. 

2.7.3.1.6  Error  detection 

The  CSL  compiler  can  recognize  many  such  errors  and  informs  the  programmer  about 
missing  or  extra  program  elements.  The  errors  detected  by  the  compiler  fall  into  two  classes, 
syntactic  and  semantic  errors.  The  following  two  sections  discuss  these  two  classes. 

1.  Syntactic  Error  Detection— a syntax  error  occurs  when  the  structure  of  the  source 
program  does  not  conform  to  the  structure  of  the  CSL  language  as  defined  by  the  syntax  of 
that  language  expressed  in  the  file  CSLIO.BNF.  The  most  common  source  of  syntax  errors  is 
a missing  terminal  symbol  such  as  or  LANRETXE.  The  parsing  process  used  by  the 
compiler  is  top-down,  so  that  a definite  goal  symbol  is  not  always  known  to  the  parser. 
Hence,  many  errors  of  this  type  result,  after  a long  futile  search,  in  the  message  “parse 
failure.”  On  the  other  hand,  the  CSL  language  contains  many  terminal  symbols  which  must 
always  occur  in  pairs;  the  parser  can  detect  the  absence  of  the  second  member  of  such  pairs 
and  point  out  the  place  in  the  program  that  it  expects  such  a symbol  to  occur  for  a 
successful  parse.  The  parser  is  often  wrong  about  the  place  in  the  program,  but  it  is  never 
wrong  about  the  absence  of  the  matching  terminal  symbol. 


354 


occurs  will  be  reported  as  a number  error. 

2.  Semantic  Error  Detection— a program  can  be  syntactically  correct  and  still  contain 
errors  which  the  compiler  can  detect.  The  following  describes  the  different  semantic  errors 
which  the  compiler  can  detect. 

The  compiler  reports  a fatal  semantic  error  when  it  detects  a reference  to  a variable  in  an 
expression  which  has  not  been  declared  at  the  point  where  it  is  referenced.  When  an 
undeclared  variable  occurs  as  a jump  destination,  the  compiler  assumes  that  it  refers  to  an 
undeclared  external  procedure.  The  compiler  lists  all  variables  of  this  type  at  the  end  of  the 
listing  file  (<input  file  name>.LST)  and  on  the  controlling  terminal. 

The  compiler  reports  a multiple  declaration  when  it  finds  more  than  one  declaration  for 
the  same  identifier  within  the  same  block  scope.  A given  identifier  can  be  declared  as  an 
EXTERNAL  variable  only  once  in  a program.  Moreover,  that  same  identifier  may  not  be 
declared  as  a local  variable  anywhere  in  the  program. 

The  CSL  language  permits  a user  to  declare  and  access  array  variables.  The  syntax  for 
both  the  declaration  and  access  requires  that  an  expression  of  some  sort  enclosed  between 
matching  brackets,  “[.  . .]  ”,  follow  each  instance  of  such  a variable.  The  compiler  reports  a 
fatal  semantic  error  when  it  finds  a variable  that  was  not  declared  as  an  array  variable 
accessed  with  an  expression  enclosed  in  brackets.  The  compiler  will  report  a reference  to  an 
undeclared  word  if  an  array  reference  occurs  with  a constant  subscript  and  the  constant 
used  does  not  address  a word  declared  for  that  array. 

The  syntax  of  CSL  requires  that  all  references  to  bits  within  a word  or  expression  be 
composed  of  literal  constants.  The  compiler  checks  to  see: 

1.  That  all  of  the  bits  referred  to  in  a reference  are  declared  for  the  variable  to  which 
the  bit  expression  (<.  . .»; 

2.  That  the  bit  numbers  in  a bit  reference  occur  in  the  correct  order;  thus,  if  “.V”  is 
declared  “A  <7:  0>”  and  referenced  “A  <0:  2>”,  the  compiler  will  report  a 
non-fatal  “bit  access  reversed”  error; 

3.  The  number  of  bits  and  words  declared  for  an  overlay  variable. 
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2.7.3.1.7  Compiler  modification 


The  compiler  for  the  CSL  language  is  based  on  a table  of  the  syntax  of  the  language  and 
two  auxiliary  files  prepared  by  the  syntax  analysis  program  GRPGEN.SAV. 

One  of  these  auxiliary  files,  CSLIO.EQV,  permits  the  user  GRPGEN  to  define  equivalent 
names  for  terminal  symbols  and  production  names.  The  second  auxiliary  file,  CSLIO.NEG, 
permits  the  user  to  associate  that  which  appears  to  he  terminal  symbols  of  the  grammar  with 
items  which  his  lexical  scanner  will  recognize  in  the  source  program.  In  CSL,  they  are 
NUMBER,  IDENTIFIER,  and  STRING. 

In  general,  the  compiler  can  be  modified  in  a fairly  straightforward  manner.  If  a syntax 
change  is  made  that  involves  new  terminal  symbols  and  new  production  names,  ordinarily, 
only  modules  CSSEM  and  CSGEN  need  be  altered.  Occasionally  a syntactic  test  may  have  to 
be  inserted  into  a parser  to  cause  a search  to  proceed  down  a different  path  in  the  syntax 
graph  if  some  condition  is  not  met. 

The  routines  SEMANTICS  in  CSSEM  and  GENERATE  in  CSGEN  are  simply  long 
SELECT  statements.  In  SEMANTICS,  the  terminal  name  passt-d  is  compared  with  a list  of 
terminals.  If  a new  terminal  is  introduced  into  the  syntax,  its  equivalent  name  must  lx> 
entered  into  the  list.  In  addition,  a call  must  be  entered  to  a semantic  routine  for  that 
terminal.  This  routine  is  written  to  perform  the  table  manipulation  and  code  generation. 

The  routine  GENERATE  is  also  a long  SELECT  statement.  The  name  passed  to  it  is  of  a 
production.  Therefore,  new  production  names  which  require  semantic  actions  must  be 
entered  into  this  list  and  a call  to  the  proper  code  generating  routine  must  be  made. 
Ordinarily,  a new  routine  must  be  written  for  each  new  production  name. 

21:2.2  Code  Generation 

The  output  file(s)  of  the  CSL  compiler  must  be  assembled  with  the  DEC  assembler 
MACRO  before  linking  them  with  a control  program  for  use  as  a simulator.  There  are  two 
basic  parts  of  the  output: 

1.  Storage  allocation,  and 

2.  Executable  code. 


These  two  parts  are  discussed  in  the  following  sections. 


2.7.3.2.1  Storage  allocation 


Thero  are  three  classes  of  variables  for  which  storage  and  names  are  required  in  a 
simulation  module: 

1.  EXTERNAL  symbols, 

2.  Internal  variables,  and 

3.  Compiler  generated  variables  and  constants. 

The  CSL  language  requires  all  EXTERNAL  variables  to  have  unique  names,  since  these 
names  will  eventually  acquire  definition  through  the  use  of  the  DEC  LINK  program. 
However,  the  block  structure  of  the  language  permits  multiple  use  of  the  names  for  internal 
variables— those  not  declared  B^XTERNAL.  The  compiler  generates  requirements  for 
temporary  viiriables  of  two  types.  Since  nonexternal  names  can  be  used  more  than  once,  and 
since  the  MACRO  assembler  does  not  have  a block  structure  capability,  all  internal  imd 
compiler  generated  variables  (and  constants)  are  assigned  compiler  generated  names  for  use 
throughout  the  simulation  module.  Two  different  types  of  names  are  assigned  to  internal 
Viiriables: 

1.  User  declared  v;u-iables,  constants,  and  pointer  values  are  assigned  names  of  the  form 
Tnn,  where  "nn”  is  a d^'cimal  number, 

2.  Compiler  generated  temporary  variables  (TEMP’s  and  KLACVs)  are  assignwl  nc  nes  of 
the  form  %nn,  where  “nn”  is  a decimal  number. 

For  all  but  the  array  variables,  the  storage  allocated  by  a storage  allocating  macro  is  one 
word.  For  arrays,  a word  that  contains  the  size  of  the  array  is  allocated,  followed  by  the 
number  of  words  declared  for  the  array.  The  word  that  contains  the  size  of  the  array  is  used 
throughout  the  simulation  to  check  for  references  outside  the  declared  array. 

The  REGISTER,  LREGISTER,  EXREGISTER,  MEMORY,  LMEMORY,  and 
EXMEMORY  macros  define  an  assembly  time  symbol  of  the  form  .^symbol  name >,  which 
contains  the  number  of  bits  intended  for  the  variable.  A symbol  of  the  same  form  with  value 
zero  is  defined  for  CONSTANT,  TEMP,  and  POINTER  variables.  (The  value  of  the  bit 
length  assembly  time  variables  throughout  the  assembly  process  are  generated  by  LENGTH 
macro  of  the  CSL  compiler. ) 

Since  symbols  within  MACRO  arc  unique  only  to  six  characters,  EXTERNAL  symbols 
should  have  names  unique  to  five  characters  (plus  the  prefix  “.”)  so  that  correct  length 
information  can  lx*  accesst'd  during  as-sembly  of  the  executable  code. 


2.7.3.2.2  Executable  code 


The  allocation  macros  use  DEC-10  registers  for  temporary  and  flag  variables  as  long  as 
they  are  available.  The  code  generation  macros  optimize  the  code  they  produce  when 
temporary  and  flag  variables  have  been  allocated  DEC-10  registers.  Variables  having  lengths 
of  zero  are  accessed  by  word  accessing  rather  than  by  byte  pointers.  Other  than  these  two 
steps,  the  code  generation  process  is  straightforward.  The  pointers  generated  by  the 
compiler  all  expect  the  address  of  the  variable  to  be  in  register  PREG,  which  is  register  17 
(Octal)  in  both  the  compiler  and  the  macros.  Accesses  that  use  compiler  generated  pointers 
are  accomplished  by  loading  this  register  before  using  the  pointer.  In  other  cases,  a pointer  is 
generated  as  a literal  during  the  assembly  process. 

2.7.3.3  Simulation 

This  section  covers  the  considerations  involved  in  utilizing  a simulation  module  that  has 
been  generated  through  the  CSL.ISP  compiler.  A simulation  control  program  is  discussed 
and  specific  simulations  are  described. 

2.7 .3.3.1  Simulation  control  considerations 

The  CSL/ISP  compiler  is  used  to  process  a register  transfer  level  description  of  a digital 
processor  into  an  executable  simulation  module.  Since  there  are  no  input  and  output 
functions  built  into  the  CSL/ISP  language,  another  module  written  in  a language  with 
input/output  support  is  needed  to  interface  the  simulator  with  the  user.  Also,  since  the 
normal  reason  for  use  of  this  type  of  simulation  is  software  or  hardware  evaluation,  it  is 
necessary  to  have  some  debugging-type  controls  over  the  simulator.  Such  controls  include  a 
complete  display  capability  for  all  simulated  memory  and  registers,  single-step  execution, 
and  breakpoints. 

2.7. 3.3.2  Processor  description  methodology 

The  description  method  was  chosen  to  provide  the  fastest  execution  time  for  a 
simulation,  while  providing  all  the  desired  debugging  control  facilities.  An  underlying 
feature  of  the  method  is  that  the  simulator  is  a single-step  routine.  Each  time  the  simulator 
is  invoked,  it  simulates  a single  instruction  and  returns.  In  this  way,  the  control  module  can 
manage  the  simulation  on  an  instruction  by  instruction  level.  There  are  a number  of  reasons 
for  this  choice.  First,  it  was  decided  that  the  execution  control  loop  should  be  invariant  over 
different  simulators.  Thus,  it  should  neither  be  necessary  nor  desirable  that  the  user  code  it 
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into  his  description.  Another  reason  is  that  the  code  generated  by  the  compiler  used  for  the 
control  program  (BLISS-10)  produces  a more  efficient  code  than  the  CSL/ISP  compiler. 
Finally,  the  program  has  a better  structure  when  the  control  and  simulations  functions  are 
separated  into  different  modules. 

.Another  feature  of  the  description  method  is  that  interrupts  are  to  be  handled  in  the 
simulator  module.  The  reasons  for  this  are  very  similar  to  those  above.  With  these  two 
constraints  on  the  processor  descriptions,  it  is  necessary  to  have  the  fetch  and  execution 
cycle  as  the  highest  level  process  in  the  processor  description.  It  should  be  noted  that 
interrupt  can  only  be  recognized  at  the  beginning  of  an  instruction  execution  cycle. 

2.7.3.3.3  The  general  control  program 

The  command  set  is  based  upon  the  console  command  set  for  the  DAIS  Intelligent 
Console.  All  commands  consist  of  a single  character  and  require  zero,  or  two  numeric  or 
single  character  operands. 

The  command  set  is  almost  totally  independent  of  the  processor  being  simulated  and 
provides  all  the  desired  debugging  features  except  a tracing  facility.  It  supports  extensive 
display  and  modify  commands  for  simulated  memory  and  registers,  and  can  support  an 
unlimited  number  of  breakpoints. 

The  tracing  facility  could  be  implemented  because  the  compiler  generates  fullword 
instructions.  The  use  of  these  instructions  eliminates  the  use  of  flag  bits  in  the  simulated 
memoiy  words  for  the  trace  facility. 

Another  feature  of  the  Simulation  Control  Program  is  the  east'  in  which  it  can  be 
configured  tor  a new  simulator  module.  The  program  has  been  structured  in  such  a way  as 
to  minimize  the  amount  of  coding  necessary  to  configure  a Simulation  Control  Program  for 
a new  simulator.  In  fact,  80  percent  of  the  program  is  independent  of  the  processor  being 
simulated.  Figure  2. 7. 3. 3-1  shows  the  execution  flow  of  a simulation  utilizing  this 
simulation  control  module. 
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2.8  COMMUNICATIONS  SYSTEMS  EVALUATION  LABORATORY 


2.8.1  Introduction 

A framework  in  which  to  relate  the  capabilities  of  the  Communications  System 
Evaluation  Laboratory  (CSEL)  is  provided  in  Figure  2. 8. 1-1.  This  figure  depicts  a standard 
block  diagram  of  a general  communication  system  consisting  of  a transmitter  (information 
source,  encoder,  modulator,  up  converter),  a channel,  and  a receiver  (down  converter, 
demodulator,  decoder,  and  information  sink).  Of  primary  interest  in  this  discussion  are  the 
carrier  systems  involved;  thus,  the  appropriate  carrier  frequency  associated  with  any  of  the 
links  of  the  system  has  been  indicated  in  the  block  diagram.  For  completeness,  it  has  been 
assumed  that  appropriate  antenna  systems  are  associated  with  the  transmitting  and  receiving 
terminals. 

The  channel  of  the  communication  system  in  Figure  2. 8. 1-1  can  take  one  of  the  two 
forms  shown  in  Figure  2.8.1 -2.  The  first  of  Uiese  involves  a single  link  between  the 
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NOTE:  Top  ripure  diows  a channel  comisting  of  a single  link;  bonom  figure,  a 
channel  with  two  links  (e.g.,  uplink  and  downlink). 


transmitter  and  receiver  terminals  while  the  second  consists  of  two  links  separated  by  a 
transponder. 


In  both  cases,  the  sources  of  contamination  are  assumed  to  produce  signals  which 
combine  with  the  information-bearing  signal  and  degrade  its  reception.  In  addition  to 
receiver  front-end  noise,  the  contaminating  signals  of  primary  interest  are  jamming  signals 
and  cochannel  and  interchannel  interference.  Likewise,  channel  effects  which  degrade 
reception  are  fading,  multipath,  and  doppler  shifts.  The  block  diagram  of  Figure  2. 8. 1-2  is 
intended  to  show  that  the  channel  effects  act  together  with  the  contamination  sources  to 
corrupt  the  desired  signal.  In  what  follows,  these  factors  are  referred  to  jointly  as 
environmental  (i.e.,  electronmagnetic)  effects. 


The  primary  role  of  CSEL  is  to  furnish  the  means  of  evaluating  communication  system 
performance  degradation  because  of  these  environmental  effects.  CSEL  provides  a user  with 
the  capability  of  simulating  the  channel  at  his  communication  system  terminal— with 
hardware  and  in  the  appropriate  frequency  band,  thus  allowing  him  to  create  an  RF  signal 
environment  suitable  to  his  application.  With  respect  to  Figure  2. 8. 1-2,  the  facility  includes 
hardware  to  generate  known  contaminating  signals,  to  combine  them  with  an 
information-bearing  signal  and  to  subject  the  signals  to  various  channel  effects.  In  addition, 
CSEL  allows  the  user  either  to  simulate  the  transponder  shown  in  the  figure  or.  in  certain 
cases,  to  employ  an  actual  (satellite)  transponder. 

As  shown  in  Figure  2. 8. 1-1,  the  significant  general-purpose  capability  of  CSEL  is  the 
creation  of  realistic  communication  channels,  which,  in  turn,  provides  the  user  the  ability  to 
test  various  communication  concepts  as  well  as  to  test  actual  communication  gear.  It  is 
implied  that  the  equipment  rec^uired  to  outfit  a complete  laboratory  communication 
system— antennas,  transceivers,  modems,  and  codecs— must,  in  general,  be  user-supplied, 
although  CSEL  does  make  available  to  users  a variety  of  such  gear. 

Despite  the  general  nature  of  CSEL  previously  described,  the  current  thrust  of  CSEL  is 
directed  at  studying  jamming  and  antijamming  techniques  for  application  to  satellite 
communication  links.  In  addition,  CSEL  makes  available  the  means  of  instrumenting 
antijamming  measures  including  programmed  frequency  hopping.  Thus,  in  Figure  2. 8. 1-2, 
the  RF  input  signals  can  be  thought  of  as  spread-spectrum  signals  whose  structure  is 
user-controlled. 

An  additional  factor  which  currently  limits  the  scope  of  potential  application  for  CSEL 
is  its  present  emphasis  on  digital  communications  systems  (although  purely  analog  systems 
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are  not  ruled  out  of  consideration).  This  is  indicated  not  only  by  the  presence  of  coders  in 
Figure  2. 8.1-1,  but  also  by  the  fact  that  the  hardware  available  for  transponder  simulation 
consists  of  a digital  signal  processor.  Thus,  system  transponders,  a block  diagram  of  which  is 
shown  in  Figure  2.8. 1-3,  appear  to  function  as  coders  even  if  the  only  operation  they 
perform  is  to  reconstitute  a digital  data  stream. 

2.8.2  Signal  and  Interference  Generator 

The  task  of  channel  simulation  in  the  Communication  Systems  Evaluation  Laboratory  is 
performed  by  two  pieces  of  equipment;  the  Signal  and  Interference  Generator  (SIG), 
sometimes  referred  to  as  the  K-band  Terminal  Simulator:  and  the  Programmable  Data 
Terminal  (PDT).  Discussion  of  the  latter  device,  used  primarily  for  transponder,  simulation, 
is  postponed  to  the  next  section. 

An  overall  block  diagram  of  the  SIG  is  shown  in  Figure  2. 8. 2-1.  This  system,  developed 
by  Computer  Sciences  Corporation,  is  capable  of  modeling  various  types  of  RF  links  and  the 
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Figure  2.8.1-3.  Transponder  binck  diagram. 
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Figure  2.8.2-1.  Overall  block  diagram  in  signal  and  interface  generator. 

signal  environments  associated  with  them.  As  the  figure  indicates,  the  SIG  is  composed  of 
four  primary  functional  elements:  (1)  analog  and  digital  baseband  sources;  (2)  RF  exciters; 
(3)  RF  combiners;  and  (4)  a digital  controller.  In  general,  the  digital  controller,  operating  on 
the  basis  of  commands  supplied  by  the  user,  is  responsible  for  configuring  the  other 
elements  so  as  to  model  the  communication  links  of  interest.  In  addition,  the  controller 
exerts  real-time  control  over  the  operation  of  these  elements  during  a test  run. 

With  reference  to  Figure  2. 8.1-2,  the  purpose  of  the  SIG  is:  (1)  to  generate 
contaminating  signals  including  jamming  and  cochannel/inter-channel  interference;  (2)  to 
combine  the  contaminating  signal  with  the  information-bearing  signal;  and  (3)  to  subject 
signals  to  link  effects,  including  fi  ling  and  doppler.’"  In  general,  the  first  task  is  performed 
by  the  baseband  sources  acting  in  conjunction  with  up-converters  located  in  both  the 

* Multipath,  mentioned  in  the  preceding  section,  is  not  instrumented,  although  plans  to  do  so  have  been 
discussed. 
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I'Xi'itors  anil  tho  oomlnnors;  tin*  second  tusk  falls  to  the  combiners;  and  the  third  'ask  is  the 
function  of  the  exciters.  In  the  purattruphs  which  follow,  the  equipment  realizinn  these  tasks 
is  de.scnbeil  in  moderate  detail. 


The  functioninn  of  (he  major  elements  of  the  SKJ  havint*  been  described,  various  ways  in 
which  these  elements  may  be  confitnired  are  explored  through  two  examples:  the  first 
conceriuxi  with  communication  via  a relay  satellite;  the  second,  with  a remotely-pilotixl- 
vehicle  communication  system. 


Since  the  emphasis  in  what  follows  is  on  the  functional  aspects  of  the  SKI,  some  liberty 
is  taken  in  the  description  of  these  elements  with  respect  to  their  hanlware  implementation. 
In  addition,  many  of  the  interfaces  available  between  user  and  system  which  provide 
maintenance  and  debuRnint?  capabilities  are  not  discussed  to  avoid  complications  which 
might  detract  from  the  primary  aim  of  describing  how  the  SIG  is  used. 
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2.8.2. 1 RF  Exciters 

The  function  of  the  RF  exciters,  three  of  which  are  included  in  the  SIG,  is  to  generate 
modulateil  L-band  signals.  These  signals  can  possess  a variety  of  modulation  formats,  can  be 
equippetl  with  anti-jamming  capabilities  in  tire  form  of  frequency  hopping,  and  can  display 
time-varying  power  levels  to  simulate  fading. 

A functional  block  diagram  of  the  RF  exciters,  shown  in  Figure  2.8.2. 1-1,  displays  the 
three  basic  functions  of  modulation,  up-conversion,  and  attenuation  they  perform.  The 
exciters  accept  inputs  from  a number  of  sources,  some  internal  and  some  external  to  the 
SIG,  as  the  figure  indicates.  In  general,  external  sources  must  he  suppliiHl  by  the  user. 

2.8.2.1.1  Modulators 

With  respect  to  their  modulation  function,  the  exciters  utilize  a 560  MHz  signal  gener- 
atixl  by  a phase-locked  oscillator  as  the  basic  carrier.  With  some  restrictions  mentioneil 
below,  an  exciter  can  modulate  this  carrier  in  any  one  of  the  following  ways:  continuous 
wave  (CW);  frequency  (FM);  phase  shift  keying  (PSK);  quadraphast'  shift  keying  (QSK); 
multiple  frequency  shift  keying  (MFSK);  and  pulse  mixlulation  (PUL)."'  In  this  context,  CW 
modulation  refers  to  no  modulation;  the  output  of  the  modulator  is  simply  the  560  MHz 
carrier.  Moreover,  PUL  modulation  refers  to  pulse  amplitude  modulation.  The  type  of 


• Th<‘  acronynw  ooiTfjipond  ti»  ('Hi'  cUnHimf^ntiitinn. 
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• modulation  to  Ih>  performtHi  by  an  exciter  is  specified  by  the  user  through  the  digital 

. controller. 

f 

f 

.\s  Figurt'  2. 8.2. 1-1  indicates,  an  exciter  can  also  accept  an  IF  signal  input  from  an 
external  source,  nwessarily  at  560  MHz.  In  this  case,  the  modulation  {>ortion  of  the  exciter 
IS  effectively  bypas.stHl. 

2.8.2. 1.2  Up-converters 

I 

j Having  producwl  or  lH‘en  suppliwl  with  a 560  MHz  IF  signal,  the  exciter  translates  this 

signal  m frequency  to  1.,-band,  corresponding  to  a carrier  frequency  in  the  liand  from  1,200 
to  1,600  MHz.  The  precise  frequency  shift  employed  in  the  conversion  varies  according  to 
the  output  of  a frequency  synthesizer  associated  with  the  exciter.  Under  the  supervision  of 
the  digital  controller,  the  frequency  synthesizer,  in  conjunction  with  an  .\16  multiplier, 
pmvides  a local  oscillator  which  is  dynamically  tunable  over  the  range  of  1,760  to  2,160 
MHz  in  steps  of  16  Hz.  It  is  by  this  means  that  a frt'quency-hopptHi  signal  is  produced 
which,  in  addition,  may  be  made  to  display  u simulated  doppler  shift. 

The  process  of  crt'uting  a frequency-hopped,  doppler-shifted  signal  takes  place  according 
to  user-specified  “patterns,"  a pattern  in  tins  case  corre.sponding  to  a list  of  frequency 
offsets  to  be  applitnl  to  the  nominal  1,-band  carrier  frequency  assigned  to  lui  exciter.  Fat- 
terns  are  interi>reted  by  the  digital  controller  anil  used  by  it  to  dynamically  vtuy  the  output 
of  the  frequency  synthesizer.  The  offset  specifieil  by  aiiy  pattern  item  may  persist  in  the 
.synthesizer  from  5 to  32,765  ms  (in  steps  at  5 ms),  the  siune  time  for  all  items  in  a given 
pattern  but  specifieil  inde()endently  for  that  pattern  by  the  user.  The  values  of  the  (nittern 
items  may  Ih'  of  any  magnitiule  provided  Uiat  they  do  not  result  in  an  out-of-tiand  fre- 
quency in  either  the  exciter  or  Ute  combiner  (discus.sed  below)  into  which  it  feeds.  In 
selecting  frequency  offsets,  the  digital  controller  chooses  doppler  pattern  items  sequentially 
from  the  list  supplied  by  the  user,  and  hop  pattern  items,  randomly.  In  both  cases,  a (ndtern 
is  limited  to  no  mon'  than  1,008  individual  items. 

2.8.2.1.3  Attenuators 

The  RF  signal  at  the  output  of  the  up-converter  is  then  passwl  through  a variable 
attenuator  which  is  dynamically  varitnl  under  the  supervision  of  the  digital  controller  to 
simulate  the  effivts  of  fading.  The  .sidection  of  fade  values  by  the  controller  is  also 
IH'rformed  with  respect  to  a user-s(H‘cified  pattern  analogous  to  that  u.sed  for  doppler  shifts. 
In  this  ca.se,  pattern  items  may  specify  from  0 to  35  ilB  of  attenuation  and  may  contain 
1,016  items. 
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2.8.2.1.4  Types  of  exciters 
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The  thrw'  exciters  of  the  SIG  are  labelled  access  1,  access  2,  and  jammer.  Although  very 
similar  in  structure,  the  various  exciters  perform  different  roles  in  the  SIG,  hence  the 
diffenmce  in  names.  With  respect  to  the  exciter  functions  described  above,  the  following 
distinctions  are  noted  t)etween  the  access  exciters  and  the  jammer  exciter:  (1)  the  access 
exciters  will  not  perform  PUL  modulation;  (2)  the  jammer  exciter  will  not  perform  FM* 
and  MFSK  modulation,  nor  will  it  perform  frequency  hopping  and  fading. 

2.8.2.2  RF  Combiners 

The  outputs  of  the  exciters  are  routed  to  one  of  four  RF  combiners  in  the  SIG  where 
they  are  translated  to  a new  RF  frequency,  suitably  attenuated,  and  then  combined  with 
one  another  and  with  other  RF  signals  originating  from  external  sources.  The  four 
combiners  operate  at  UHF,  L-band,  X-band,  and  K-band,  respectively. 

A block  diagram  illustrating  the  combiner  operation  is  shown  in  Figure  2. 8.2. 2-1.  Of  the 
five  input  ports  indicated  in  the  diagram,  three  are  permanently  associattxl  with  the  three 
exciters  and  two  are  available  for  RF  signals  from  external  sources.  The  exciter  inputs  are 
independently  translated  to  carrier  frequencies  appropriate  to  the  given  combiner  and 
subsequently  attenuated.  Although  neither  the  degree  of  frequency  shift  nor  that  of 
attenuation  is  dynamically  variable,  as  is  the  case  in  the  exciters,  both  of  these  parameters 
are  user-selected  to  establish  nominal  signal  frequencies  and  power  levels. 

2.8.2.2.1  UHF,  L-band,  and  X-band  combiners 

The  UHF,  L-band,  and  X-band  combiners  are  broken  into  two  sections,  uplink  and 
downlink,  which,  with  respect  to  the  combiner  operation  indicated  in  Figure  2. 8.2. 2-1, 
operate  independently.  A more  detailed  block  diagram  of  these  combiners  is  shown  in 
Figure  2.8.2.2-2.  Note  that  both  access  exciter  inputs  are  directed  to  the  same  section  of  the 
combiner,  independently  of  the  routing  of  the  januner  exciter  input.  Note,  moreover,  that  a 
pair  of  external  signal  input  ports  are  provided  for  both  uplink  and  downlink  section.  In 
each  case,  the  signals  pass  through  a switch  whose  status  is  user-selected. 

Both  uplink  and  downlink  sections  of  the  UHF  and  L-band  combiners  operate  in  the 


• More  precaely,  there  exists  no  internal  source  for  frequency  modulations  of  the  jammer  exciter;  external 
sources  may  be  used,  however. 
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Fifurt  2.8.2.2-1.  Gentral  block  diofram  of  RF  combiners. 
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same  frequency  band.  For  the  UHF  combiner,  this  band  is  240  to  400  MHz;  for  the  L-band 
combiner,  1,200  to  1,600  MHz.*  In  the  X-band  combiner,  however,  the  uplink  section 
operates  in  the  frequency  band  7,900  to  8,400  MHZ  and  the  downlink  section,  in  the  band 
7,250  to  7,750  MHz.  In  all  cases  the  attenuation  may  be  set  to  achieve  from  0 to  99  dB  of 
attenuation. 

2.8.2.2.2  K-band  combiner 

The  K-band  combiner  is  structured  somewhat  differently  than  the  others.  In  the  case  of 
this  combiner,  there  is  no  strict  differentiation  into  uplink  and  downlink  sections;  as  a 
consequence,  some  of  the  flexibility  of  the  other  combiners  is  sacrificed.  Furthermore, 
frcxiuency  translation  of  the  exciter  inputs  places  the  signals  independently  in  one  of  two 
non-contiguous  frequency  bands— 36,640  to  37,040  MHz  or  37,840  to  38,240  MHz.  Im- 
plied, therefore,  is  that  each  of  the  mixing  operations  shown  in  Figure  2. 8. 2. 2-1  actually 
occurs  in  one  of  two  parallel  paths,  the  path  utilized  depending  on  the  frequency  chosen  for 
that  exciter  input. 

The  K-band  combiner  differs  in  several  other  respects  as  well.  As  Figure  2. 8. 2. 2-3 
indicates,  a switching  arrangement  exists  whereby  either  of  the  following  output 
configurations  may  be  realized:  a single  output  channel  fed  by  all  the  exciter  and  external 
inputs;  and  dual  output  channels,  one  fed  by  the  jammer  exciter  and  external  inputs  and  the 
other  by  the  access  exciter  inputs.  In  addition  to  this  distinction,  the  combiner  provides  a 
different  attenuation  scheme.  In  the  first  place,  the  individual  attenuation  associated  with 
the  exciter  inputs  provides  only  0 to  50  dB  of  attenuation;  an  additional  60  dB  of 
attenuation  is  achieved  by  a manual  attenuator  associated  with  the  “combined  output” 
channel.  In  the  second  place,  from  0 to  99  dB  of  attenuation  may  be  applied  manually  to 
one  of  the  external  inputs  as  the  block  diagram  indicates.  Although  the  user  must  set  those 
two  extra  attenuators  manually,  he  is  aided  in  this  task  by  measurements  supplied  by  the 
digital  controller. 

2.8.2.2.3  Exciter/combiners  interface 

The  interconnections  between  the  exciters  and  the  combiners  are  illustrated  schemat- 
ically by  the  switching  network  of  Figure  2.8. 2.2-4.  In  this  diagram,  no  more  than  one 
crosspoint  in  a given  row  may  be  closed.  It  follows,  therefore,  that  a given  exciter  may 


• Currently  the  L-band  combiner  perform.s  no  frequency  conversion  on  exciter  inputs.  Modifications 
currently  in  progress  will  alter  this  situation,  the  overall  effect  of  which  will  be  to  increase  the  frequency 
hand  of  this  combiner  to  the  range  800  to  2,400  Mllz. 
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I Figurt  2.8.2.2-4.  Excitar/combiner  inttrrahtionship. 

1 

i 

! be  connected  to  at  most  one  combiner.  It  is  also  to  Im?  noted,  although  the  figure  does  not 

show  it,  that  the  switches  in  the  combiners,  which  direct  access  exciter  inputs  to  uplink  or 
) downlink  sections,  are  ganged  so  that  should  two  access  exciter  outputs  be  directed  to 

j different  combiners,  they  nevertheless  would  both  be  routed  either  to  the  uplink  sections  of 

I their  respective  combiners  or  to  the  downlink  swtions. 

f 

» 

i 2.8.2.3  Baseband  Sources 


Five  types  of  bast'band  signal  sources  exist  within  the  SIG  to  achieve  the  types  of 
modulation  mentioned  earlier. 

The  first  type  corresponds  to  no  signal  source  whatsoever,  i.e.,  a ground  connection  to 
the  modulator  of  an  exciter.  The  result  is,  therefore,  CVV  modulation. 

The  second  of  these  sources  consists  of  two  independent  white  noise  generators  paired 
respectively  to  the  two  access  exciters.  The  output  signal  Iwindwidth  of  these  generators  may 
be  selected  independently  from  the  following  list:  4,  12,  20,  48,  144,  or  240  kHz, 
Depending  on  the  bandwidth  chosen,  the  signal  produced  by  a generator  simulates  that 
obtained  by  frequency-division  multiplexing  from  one  to  sixty  voice  channels,  each  4 kHz 
wide.  This  signal  is  then  input  to  the  corresponding  exciter  to  produce  FM  modulation. 

The  third  type  of  source  consists  of  a pulse  generator  whose  output  drives  an  AM 
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j mi'iliilator  m th«*  jammor  oxoitcr.  prvHiiu'in^  I’l’l.  iiuHlvilatioiv.  rh«‘  puls»-  m-uerulDr  is  i apal>l«' 

! I'f  outpiittint:  a poru'vlu-  on  off  signal  iii  wliioli  l>oih  tho  oii-tmu'  and  tho  off-tmu*  may  tv 

seltvtixt  iiulop«‘iuU>ntly  frv>m  liio  ranno  0 5 tv>  32,7t*7.5  ms  m imm'monts  of  0.5  ms. 

I I'ho  final  s»tviro«'  ivnsists  i>f  tlu'  fiwiin'iu'v  syntlu'siior  itself,  whieli  m addition  to 

j 

»:«Mi«'ratmn  fn'niioiu  y hops  and  doppler  sliifts,  may  also  Iv  pro»;ramm»‘(.l  to  piXKiiuv  MFSK 
nuHhilation.  I’he  modulating  si>;nal  is  anain  spoeifu'vl  by  a pattern  as  an*  fn'nueney  hops,  the 
I only  differenee  hein^  a fteqiietu  y offset  limitation  of  10  klU  m the  present  < as»v 

I 

! 

In  addition  to  the  internal  sv>iiie'’,s  just  de,si'rilH\i,  the  Sltl  al.so  makes  provision  for  the 
eoni'.is'tum  of  external  liasehaiul  >oiiiees  to  affeet  either  analog;  (KMl  or  dijiital  tl’SK,  QSKt 
modiilativm  in  an  exeitc'r  The  major  eonsideratii>n  in  i|iialifyinjj  siieh  a soiiive  for  use  with 
the  SK't  IS  that  it  produees  a si>;nal  eompatihle  in  bandwidth  and  iK'wer  level  with  those 
produe*xi  by  the  mtenial  .soiirees, 

2.8.2.4  OigitAl  Controller 

The  fnni'tii'ii  of  supervising  the  elements  dessTibtxl  above  is,  as  has  Iven  mdieated,  the 
task  at  the  digital  vontroller  I'his  rv'le  is  filKxi  by  a I’Ol'  11  20  minieomputev  with  I IK  of 
memory.  exteiuUxl  arithmetie  unit,  and  the  following  peripherals:  dual  cartridge  ihsk  drives, 
a mannetie  tape  unit,  an  ,\SK  33  teletype,  two  alphanumerie  vi^eo  displays,  a eanl  reader,  a 
paper  tape  unit,  a line  printer,  aiul  an  X Y plotter.  The  teletype  and  vuieo  displays  provide 
mteraetive  mterfaees  with  the  system. 

I'he  eomputer  is  prvs>;ramm«Hl  to  aa  ept  from  the  user  s«Hjuenee  of  eomnumds  whieh 
pertain  to  the  various  switches  and  parameters  identifitxl  above.  It  interpix'ts  these 
commands  ami  prxvmls  to  confij;urt'.  in  so  doin^,  checkin^;  for  any  equipment 
malfunctions,  .\fter  perfonnmjs  the  set  tip  task,  the  contix'ller  then  supervises,  m real-time, 
the  operation  of  the  SKI  during  an  experimental  r\in  of  the  laboratoPi'  communication 
system,  ajjain  monitorinj;  txpiipment  for  malfunctions. 

2.8.2.5  Illustrative  Experimental  Configurations 

Dne  illustration  of  the  us*'  of  the  SKI  is  pnwultxl  by  the  pr*v»;ram  for  which  t'SKl.  was 
I'riijinally  formetl,  namely  an  investigation  of  the  possibility  of  usint;  the  Liiuvln 
Kxperimental  Satellites  (LKSl  S and  ‘3  with  Uie  .\ifvanc»Hf  .Virlvnie  (.'ommand  I'ost.  I'he 
satellites,  opemtintt  at  Ka-band  (3t?-38  ClUzl,  ar»'  identifunl  with  the  transponder  in  Ktjmre 
2.8. 1-2;  they  perform  the  ftinctions  characteristic  of  such  a device.  incUidins  decinlinj;  and 
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rtvoilint;.  It  follows,  then* fore,  that  the  communication  channel  of  interest  consists  of  twro 
separate  links.  The  experimental  setups  descrilietl  here  actually  use  LES  8 or  9 to  connect 
(see  Figure  2.8,2.5-11  to  connect  these  links;  the  next  section  descrihes  simulating  the 
satellite  with  the  Progrummahle  Data  Terminal. 

Figure  2. 8. 2. 5-2  and  2. 8. 2. 5-3  show  CSEL  configurations  appropriate  for  U'sting 
air-to-ground  and  ground-to-air  K-hand  communication  channels  which  use  LES  8/9, 
respectively.  The  K-hand  modem  and  Ka-hand  terminal  shown  in  the  figures  Represent 
qualification  models  identical  to  those  propostni  for  actual  use.  The  3-ft  antenna  is 
controllwl  hy  the  Ka-band  terminals,  the  10-ft  antenna,  by  a PDP  11/45.  .\11  of  this 
wjuipment  is  part  of  CSEL.  (See  Section  2.8.4.) 

In  Figure  2. 8. 2. 5-2,  showing  the  air-to-ground  channel,  the  signal  transmitteii  by  the 
terminal  is  down-convertiHl  to  560  MHz  and  fed  into  one  of  the  access  exciters  where  the 
fade  and  doppler  are  introduced.  The  output  of  tlie  exciter  is  routed  to  the  K-band 
combiner  when*  it  is  conrupU*<l  by  a jamming  signal  generated  by  the  jammer  exciter.  The 
resulting  signal  is  then  transmittetl  by  the  three-ft  anU'nna  to  LES  8'9. 

The  signal  retumt'd  from  the  satellite  is  picked  up  by  the  10-ft  antenna,  preamplifii'd, 
and  relayed  to  the  receiver  of  the  Ka-band  terminal,  from  which  the  final  output  is 
obtained. 

Figure  2. 8. 2. 5-3  corresponds  to  the  reverse  proce<lure  of  that  just  described.  Note  that 
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Fijurt  2.8.2.5-1.  Typical  LES  8/9  operation. 
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3-FT  DISH  10-FT  DISH 


Fifure  Z8.2.5-2.  CSEL  coirfiguntion  for  testing  K-band  air-to-fround  communication 
channel  through  LES  8/9. 


10-FT  DISK 


3 FT  DISK 


JAMMER 

EXCITER 


K-BANO 

COMBINER 


FADE  AND 
DOPPLER  H 
CONTROL 


ACCESS  1 
EXCITER 


FREQUENCY 

CONVERTER 


Ka-BAND 

TERMINAL 


Ka-BAND 

MODEM 


INPUT/OUTPUT 

Figura  2.8.Z6-3.  CSEL  configurttion  lor  totting  K-band  ground-to-air  ccmmunicotion 
channol  through  LES  1/9. 


in  both  cast's  it  is  only  the  upliitk  which  is  jammed,  since  the  directivity  of  the  K-band 
antenna  renders  jamming  of  the  downlink  difficult. 


Figure  2.8.2.5-4,  on  tire  other  hand,  depicts  an  alternative  air-to-ground  communication 
channel  in  which  both  uplink  and  downlink  are  susceptible  to  jamming,  the  latter  bet'ause  it 
is  at  UHF  instead  of  K-band  (the  UHF  terminal  represents  that  at  a ground  command  jxist). 
To  simulate  this  situation,  one  of  the  access  exciters  is  usetl  to  generate  a jamming  signal, 
while  the  other  continues  to  provide  simulated  doppler  shift  and  fading.  In  all  oUrer 
res|H>cLs,  however,  the  configuration  shown  is  a direct  analog  of  that  in  Figure  2.8.2. 5-2. 
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Figure  2.8.2. 5-5  shows  Uie  experimental  configuration  for  the  reverse  ground-to-air 
channel.  Except  for  the  use  of  UHF  on  the  uplink  to  the  satellite,  this  setup  is  identical  to 
Figure  2.8.2. 5-3.  It  should  be  noted  that  both  the  UHF  modem  and  terminal  (ARC  151)  are 
part  of  the  CSEL  equipment  inventory. 

I 

\ stvond  illustration  of  the  use  of  the  SIG  is  provided  by  a communications  system 
currently  being  configured  in  CSEL.  The  system  of  interest  in  this  case  involves  the 
transmission  at  imagery  from  a remotely-piloted  vehicle  (RPV)  to  a command  )X)st  over  an 
L-band  link.  Of  interest  is  the  extent  to  which  jamming  affects  the  quality  of  received 
images  when  various  bandwidth  reduction  and  compression  schemes  are  used  to  combat  it. 
In  particular,  it  is  desired  to  determine  minimum  signal-to-noise  ratios  which  can  be 
' tolerated  before  the  RPV  can  no  longer  be  remotely  piloted  to  a desired  degree  of  accuracy. 

To  model  this  channel  on  the  SIG,  the  experimental  setuj)  of  Figure  2.8.2.5-6  is 
I currently  used.*  \ video  signal  generated  from  the  terrain  board  at  AMRL  is  transmitted  to 

i CSEL  at  AFAL.  The  received  signal  i^;  demodulated  and  the  resulting  baseband  signal  input 

to  a lladamand  transformer  to  reduce  its  bandwidtli. 

A TERRACOM  transmitter  operating  at  1,825  MHz  in  conjunction  with  a frequency 
1 converter  produces  a 560  MHz  IF  signal  for  input  to  the  access  1 exciter.  I'here  the  signal  is 

' up-converted  to  L-band  and  faded,  after  which  it  is  combined  with  a jamming  signal  in  the 

I L-band  combiner. 

The  output  of  the  combiner  is  converted  to  2,225  MHz  for  input  to  a TERRACOM 
receiver.  The  output  of  the  rt*ceiver  is  inverse-transformed,  and  after  scan  conversion, 
■ display  I'd  on  a CON  RAC  display.  The  feedback  path  shown  represents  control  of  the  terrain 

hoard  camera  to  simulate  piloting  of  an  RPV. 

2.8.3  Programmable  Data  Terminal 

The  Programmable  Data  I'erminal  (PDT)  developed  by  GTE  Sylvania  consists  of  a 
Programmable  Signal  Processor  (PSP)  mated  with  a Flexible  Frequency  Hopping/Pseudo 
Noise  (FFH/PN)  Modem.  The  function  of  this  equipment  in  the  Communication  Systems 
Evaluation  Laboratory  is  primarily  that  of  simulating  the  operation  of  a (satellite) 
transponder  of  the  sort  pictured  earlier  in  Figure  2. 8. 1-3.  It  should  be  noted  at  the  ovitset. 


• It  .should  bs'  noUMi  Ihst  Ihv  lUtMlifimlions  lo  Ihe  I,  hand  i-apahdilics  of  the  Slli  monlioni-d  earlier  are 
motivated  by  this  exp«‘rimenl. 
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HfMra  2.I.2.S-S.  CSEL  confiiarition  for  ttstint  UHF/K-band  |ro«ad-to-«ir 
commuoicitian  chonnal  throufh  LES  1/9. 


TERRAIN 

BOARD 


Fi|ura  2.t.2.S-6.  CSEL  configuritton  to  porform  RPV  iomming  txporiiiMOts. 

however,  that  the  PDT  is  capable  of  operating  in  a stand-alone  fashion  as  well.  An  overall 
block  diagram  of  the  PDT  is  shown  in  Figure  2.8.3-1. 

2.8.3. 1 FFH/PN  Modem 

The  FFH/PN  Modem,  as  an  element  of  the  PDT,  performs  two  general  tasks:  (1)  the 
down-conversion  of  wideband  IF  signals  to  produce  both  in-phase  (1)  and  quadrature-phase 
(Q)  baseband  signals;  (2)  the  generation  of  wideband  IF  signals  which  are  either  FSK  or 
QSK  modulation  (or  both).  In  both  cases  the  nominal  IF  carrier  frequency  used  is  either  70 
or  700  MHz.  Thus  the  modem  may,  in  principle,  be  interfaced  directly  to  either  a VHF  or 
UHF  transceiver  terminal.  Likewise,  the  modem  can  operate  in  a wraparound  fashion  as 


) 
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Physically,  the  modem  comprises  two  RF  drawers  which  contain  identical  components 
in  the  form  of  frequency  synthesizers,  mixers,  and  QSK  modulators.  Specifically,  five  func- 
tional modules  are  identified  in  each  drawer:  receiver,  receiver  frequency  synthesizer,  re- 
ceiver auxiliary  generator,  transmit  frequency  synthesizer,  and  transmit  auxiliary  generator. 
(The  QSK  modulator  is  located  in  the  last  named  module.)  Of  these  modules,  it  is  only  to  be 
noted  here  that  the  frequency  synthesizers  are  perhaps  the  most  important,  since  it  is  their 
function  to  act  as  rapidly  varying  oscillators  needed  both  to  down-convert  and  to  generate 
frequency-hopped  signals. 


The  RF  drawers  are  each  controlled  independently  by  the  PSP.  Thus,  with  respect  to 
either  drawer,  the  PSP  generates  transmit  and  receive  control  words  which  determine  the 
following  model  parameters: 


1.  Nominal  receiver  IF  (70  or  700  MHz); 

2.  Nominal  transmitter  IF  (70  or  700  MHz); 

3.  Receiver  bandwidth  (narrowband  or  wideband); 

4.  Transmitter  key  (on  or  off); 

5.  Receiver  synthesized  frequency; 

6.  Transmitter  synthesized  frequency. 

In  the  last  two  items,  there  are  available  224  different  frequencies  with  which  to  process  and 
generate  frequency-hopped  and  FSK  signals.  The  synthesizers  are  capable  of  rapid  shifting 
from  one  frequency  to  another  (at  least  every  five  ms).  In  addition  to  the  items  just 
mentioned,  the  PSP  can  also  pass  a data  stream  to  the  QSK  modulator. 

The  I and  Q baseband  signals  produced  by  the  modem  are  routed  to  the  PSP  through  a 
commercial  12-bit  A/D  converter  operating  at  variable  sampling  rates  up  to  50  kHz.  Before 
being  digitized,  however,  the  signals,  normally  spanning  a DC  to  600  kHz  video  bandwidth, 
may  be  analog  filtered  if  desired.  Two  low-pass  filters,  with  cutoff  frequencies  of  1200  and 
3500  Hz  are  currently  provided.  Alternatively,  a user  may  patch  in  his  own  filter  to  process, 
for  example,  FDM  signals. 

A final  component  of  the  FFH/PN  Modem  is  a noise  tfist  set  which  allows  the  user  to 
create  a controlled  signal-to-noise  ratio  on  the  700  MHz  input  of  either  RF  drawer.  Thus  the 
test  set  contains  a noise  source  (nominal  110  MHz  bandwidth)  and  a combiner  to  sum  the 
output  of  the  noise  source  and  a 700  MHz  signal.  The  corrupted  signal  is  then  sent  to  the 
chosen  IF  receive  port. 


% 


2.8.3.2  Programmable  Signal  Processor 


The  PSP  is  representative  of  current  digital  computers  of  the  same  sort  in  its  ability  to 
IH'rform  in  nuU  time  a variety  of  high  speed  digital  signal  processing  functions;  detection, 
filtering,  coding/decoding,  etc.  Thus,  with  respect  to  the  FFH/PN  Modem,  the  PSP  is 
capable  of  handling  simultaneously  the  following  functions:  (1)  detection  of  the  digital 
data  carriwl  on  the  I and  Q baseband  signals;  (2)  generation  of  output  digital  data  to  drive 
the  transmit  fn*quency  synthesizer  (FSK  modulation)  and/or  the  quadraphase  modulator 
(QSK  or  PSK  modulation);  and  (3)  generation  of  frequency  synthesizer  control  words  to 
enable  the  reception  and  transmission  of  frequency-hopped  signals. 

To  accommodate  the  throughput  rate  implied  by  these  activities,  the  PSP  has  high  speed 
memory  (500  ns  cycle  time)  and  a high  speed  arithmetic  unit  (8  ms  for  a 256-point  complex 
FFT).  The  machine  uses  16-bit  data  words  and  32-bit  program  words;  currently  2,048  words 
of  both  data  memory  and  program  memory  are  available.  A block  diagram  of  the  PSP  is 
shown  in  Figure  2.8.3.2-1. 

The  PDP  11/20  (discussed  above  in  conjunction  with  tlie  SI6)  acts  as  a host  computer 
for  the  PSP.  Thus,  program  development  for  the  PSP  can  be  carried  out  on  the  more 
convenient  minicomputer  and  the  results  entered  directly  into  the  PSP.  In  addition,  data  can 
be  passed  between  the  two  machines  during  real-time  experimentation. 

Complementing  the  digital  I/O  interfaces  with  tlie  FFH/PN  Modem  and  the  PDP  11/20 
are  two  serial  interfaces  for  peripherals  and  three  D/A  outputs  for  analog  display  devices. 
Finally,  a modem  control  panel  is  provided  for  monitoring  and  controlling  the  entire  PDT 
operation  through  the  PSP. 

2.8.3.3  Application  of  the  PDT 

Use  of  the  PDT  to  simulate  the  LES  8/9  satellites  is  straightforward.  With  resi^ect  to 
external  hardware,  one  need  only  substitute  frequency  converters  for  the  antennas  shown  in 
Figures  2. 8.2. 5-2  through  2.8.2.5-5,  in  order  to  convert  between  the  RF  frequency  used 
(K-band  or  UHF)  and  700  MHz.  The  PDT  configuration  appropriate  to  the  application  is 
shown  in  Figure  2.8.3.3-1,  in  which  the  operation  to  be  performed  by  PSP  software  is 
displayed  as  well.  These  operations,  of  course,  are  those  mentioned  at  the  beginning  of  the 
preceding  Section  2.8.3.2. 

In  addition  to  the  LES  8/9  software,  three  other  programs  have  been  written  to  run  on 
the  PDT.  With  these  programs,  the  system  can  operate  as; 
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Fipn  2.I.3.2-1.  Pro|ra.iitMUt  tifMl  praccwtr  fuaclioiNl  Mock  diafram. 


Fifarc  Z.I.3.3-1.  ProframmaWt  Ma  tariwMl  aiMlaliai  LES 


1.  A 75  bps.  full-duplex,  8’tur>’  FSK,  slow  fretiuency-hopping  modem  employing  a nite 
1/3  convolutional  encoder  and  a Viterbi  decoder; 

2.  A 75  bps,  full  duplex,  8‘ary  FSK,  fast  fretiucncy -hopping  modem  employing  a rate 
1/3  convolutional  encoder  and  a decision  feedback,  coset  leader  decoder; 

3.  A 2, -too  bps,  full  duplex  cepstrum  vocoder  . 

2.8.4  Additional  Communication  Equipment 

In  addition  to  the  general-purpose  elements  of  the  Communication  System  Evaluation 
Laboratory  described  in  the  preceding  two  sections,  are  several  hardwart'  systems, 
mentioned  only  in  passing,  which  to  a degree  are  spei'ial-purpose  equipment  bvit  nevertheless 
serve  to  solidify  the  capabilities  of  the  laboratory.  Most  of  tins  equipment  was  originally 
assemblwl  for  the  satellite  communication  experiments  and  includes  the  following 
significant  items: 

1.  Ka-Band  Airborne  Communications  Terminal; 

2.  SHF  .Mrborne  Communications  Terminal;  and 

3.  Rwftop  Antenna  Facility. 

.-Vdditional  etpiipment  cum'ntly  tieing  assembled  for  the  RPV  experiments  includes  the 
following; 

1.  TERRACOM  L-Band  Communications  Terminals; 

2.  Motion-CompensaUnl  Video  Sc'an  Converter;  and 

3.  CONRAC  Display. 

2.8.4.1  Satallita  Communication  Equipment 

The  satellite  communication  equipment  just  listeil  is  intended  for  use  in  corgunction 
with  two  satellite  systems,  DSCS  II  and  LES  8/9.  The  former  system  operates  at  X-lvand 
(uplink.  8.040  8.280  MHz;  downlink,  7,315/7,555  MHz):  the  latter  operates  at  Ka-band 
(uplink,  38'36  GHz;  downlink,  36/38  GHz)  as  well  as  UHF  (225-400  MHz). 

Except  for  the  friHpiency  bands  which  they  use,  the  airborne  communication  terminals 
art'  structurt'd  similarly.  Thus  each  terminal  is  comprised  of  the  standani  thiw  major 
elements:  uplink  transmitter,  downlink  receiver,  and  antenna  system.  Both  systems  ust'  the 
same  3-ft  disk  antenna  ((Wt  of  the  rooftop  facility),  the  scan  of  which  is  controlltnl  by  the 
(tracking)  receiver  for  spatial  acquisition,  and  lx)th  provide  automatic  doppler  compensation 
of  transmitteil  and  rt'ceivetl  signals. 
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The  Ka  l)anii  torminiil  transmitter  aeoepts  IF  inputs  at  700  atul  952.4  MHz.  It 
upconverts  either  to  the  reeeive  frequeneies  of  DSCS  11.  The  receiver  priKluees  IF  outputs  at 
870,  700,  and  70  MHz  for  LES  8'9  and  at  700  Mllz  for  DSCS  11. 

The  SHF  terminal  transmitter  accepts  IF  inputs  at  70  or  700  MHz  and  upconverts  them 
to  DSCS  II  rtveive  frtKiuencies.  The  receiver  performs  the  opposite  function. 

The  major  component  of  the  rooftop  antenna  facility  is  a 10-ft  panilwlic  reflector, 
< desitined  to  operate  at  K-hand,  with  a cofisenrain  feet!  system  utilizing;  an  11-in.  hyperbolic 

subreflector.  The  ant4'nna  is  mounUHl  on  a Scientific  .Atlanta  pedestal  allowint;  variable 
sptHHl  scimnins  through  360°  of  iuimuth  and  90°  of  elevation  The  entire  unit  is  enclostHl 
within  a high  transmittance,  inflatable  radome.  Significant  performance  parameters  of  the 
system  are  shown  in  Table  2. 8. 4. 1-1. 

The  antenna  pointing  system  functions  in  one  of  four  modes:  designation,  acquisition, 
active  tracking,  and  passive  tracking.  The  first  mode,  designation,  refers  to  manual  antenna 
pointing.  It  is  followtHl  by  tlie  acquisition  mode  in  which  the  antenna  is  scannwl 
automatically  over  a specifiwl  circular  stvtor  until  the  received  signal  exceeds  a preset 
threshold,  at  which  point  the  st'arch  is  terminatixl.  The  scanning  pattern  consists  of  13 
concentric  circles  covering  2.5  to  25  planar  degrees. 

In  the  active  tracking  mcxle,  a conical  scan  is  used  in  which  the  main  antenna  beam  is 
mutated  at  65  Hz  by  rotating  the  subreflector.  By  setting  the  squint  angle  to  yield  a 
crossover  loss  of  approximately  0.5  dB,  the  system  can  achieve  a tracking  accuracy  of  0.02 
degrees. 


TABLE  2.1.4.1-t.  PERFORMANCE  PARAMETERS  OF  IB-FT  K-BANO  ANTENNA 


Diamttir 

10  ft 

B 

Otsign  Gain 

5Sd8 

Skialobas 

-17  dB  balow  psak 

Polarization 

Both  ri|ht-  and  laft-hand  circular 

VSWR 

Lass  than  1.S 

RF  Isolation 

20  dB  batwssn  transmit  and  racaiva  channals 

IMwaguida  iniartion  Ion 

Lass  than  2 dB 

Slow  rats 

±10  dsgroa/s 

Baam  width 

0i2  dagraa 

Fraqusncy  band 

Transmit:  34-40  GHz 

Racaiva;  3440  GHz 
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In  l>oth  tlu>  acquisition  and  active  tracking  modes  control  over  the  antenna  is  exerciswl 
hy  the  Ka-liand  communications  terminal  descriheil  above.  In  the  passive  tracking  mode, 
however,  the  antenna  is  controilevl  hy  a I’DP  11  45  minicomputer;  thus,  usinj;  satellite 
ri'fraction  and  ephemoris  data,  the  computer  derives  appropriate  azimuth  elevation  data  and 
points  the  antenna  acconlin^jly. 

I 

2.8.4. 2 Video  Transmission  and  Display  Equipment 

Section  2. 8. 2. 5 discussed  the  application  of  the  SKI  to  lire  transmission  of  imagery  from 
an  RPV.  In  orvler  to  perform  e.xperiments  in  this  area.  CSEL  is  Ihmiih  equipped  with  selected 
video  processing;  and  display  capabilities.  In  addition  to  the  TERR.At'OM  terminals, 
desiTibed  earlier,  which  enable  transmission  and  reception  at  L-band,  the  facility  is  to 
contain  equipment  required  to  study  bandwidth  reduction  ttvhniques  (frame  rate 
reiluction)  and  bandwidth  compression  techniques  (two-dimensional  imatte  tninsformation). 

In  the  envisioned  confitturation,  the  terrain  boaixl  camera  (see  Fitture  2. 8. 2. 5-6)  is 
' capable  of  reducing  both  the  number  of  full  video  frames  transmitted  (ler  second  and  the 

scanning  rate  usetl  for  each.  .-\s  a result,  a bandwidth  reduction  is  achievable.  .•\t  the  display 
' console,  the  reduced  frame  rate  is  adjusted  by  a PDP  1 1 /05-based-motion-compensaUHl  scan 

converter.  This  device  affects  interpolation  l>etween  successive  received  frames  to  smooth 
out  the  video  display. 

Between  the  two  operations  just  descrilied,  each  video  frame  is  Hadamard-trimsformed 
and  the  resulting  coefficients  truncated  to  produce  a bandwidtli  compression  of  (vrhaps 
10:1.  .After  transmitting  this  signal  over  the  simulated  channel,  an  inverse  transform  is 
applied  to  obtain  the  input  to  the  scan  converter.  Both  the  direct  and  inverse'  Hadamartl 
transforms  are  to  be  performed  by  special-purjiose  digital  hardware  now  being  constructed. 

The  equipment  just  dese'ribed.  when  integratt'd  with  the  SIG,  will  give  CSEL  a rather 
unique  capability  in  studying  the  ability  of  bandwidth  reduction  and  compression  tech- 
niques to  enhance  the  antijam  performance  of  video  links. 
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